Good day -

I am having a bit of deja-vu on this one. This just bit me again in a report. Seems the STR() conversion tool has problems when converting string to STR(). No reason why you would want to do this other than the coder here was lazy and failed to check what the map was on a specific variable. In any case, doing so yields the following results. I feel this is a "glitch" in ashell... but we also have to be smarter when coding these sorts of things.

Simple example:
MAP1 A$,S,2
MAP1 A,B,1
A=1
A$="AB"

?A$
?STR(A$)
?A
?VAL(A)

Results:
.run fj1
AB
0
1
1

Consequently, printing the VAL() of a numeric field seems to leave well enuf alone.

SO just reporting this here as a caveat emptor...

AlphaBasic's automatic string/numeric conversion logic is generally considered a great convenience, but does lead to gotchas like this. The underlying fundamental problem is that every operation and function, with the exception of the + (which could be treated as enter addition or concatenation), has an explicit expectation for its argument types. If those expectations are not met, then the arguments are converted prior to the operation or function being executed. So for example (a mod b) expects the arguments to be numeric values. If they are strings, they will first be converted to numbers before the mod operator executes.

So in the case of STR(x), if x is not a numeric value, it gets converted to one before the STR() function executes. The conversion operation is effectively VAL(x), and VAL("AB") is zero.

Obviously, in this case, it seems a bit stupid to go through that double conversion, especially when it changes the expected result, when it would have been so much simpler to just treat it as a NOP. In other words, change the definition of STR(x) to be equivalent to just x if x is already a string.

It would require a special carve-out in the compiler to treat STR() differently than other functions, but that's not out of the question. It could also be handled purely at runtime, without any change to the compiler. The main concern is that it does change behavior, usually considered a negative (although in this case, probably a positive).

Perhaps we should put it out to a vote?

TBH its probably more of a nuisance than anything else. That plus changing legacy behavior (like probably 50+ years, waaaay before Herman started programming) might be more harmful than positive. While I agree the actual function is "flawed", just have to be aware...

So this more of a public service announcement? I vote no need to repair at least not for me.

I should add that I'm not 100% whether it has been this way for 50 years, or got quietly introduced somewhere along the line. Perhaps if someone has access to an actual AMOS box they might be able to try it there. The original documentation does not give any clue as to whether there was an exception if the argument was already a string

I'd also like to re-emphasize your point that the problem does not affect VAL(a), because numbers can always be converted to string and back again without a change in value. So there's an asymmetry between STR(x) and VAL(a) which adds additional camouflage to the trap.

And Frank, it’s only been 44 years for me.

Been coding since you were 10

Exactly!

It should be noted that the STREXPR$() function, unlike STR(), does not suffer from the above problem. Even though it was intended to be used on more complicated expressions, it also works on simple string arguments. For example:

RIP Herman