Addition operator does not properly handle implicit conversions

[ThinBuffalo]

Bug: Addition operator does not properly handle implicit conversions

Both of those code blocks should yield the same result (6). However the first does not. In the first rule, the expected implicit conversion to a numeric does not occur and it results in 60

The Set (Temp) in the second rule converts the string “6” to a numeric (or the variable is subsequently treated as a numeric) so the second rules results in the expected result of 6

Further testing with other operators yields these results

String “6” + 0 // 60 (wrong)
String “6” - 0 // 6 (correct)
String “6” * 1 // 6 (correct)
String “6” / 1 // 6 (correct)

Note: It could be argued that the existing implementation is appropriate so that users can concatenate numerics into a single string. But that’s a bad argument IMO as

1. the 2 rules shown would be expected to yield the same result,
2. implicit conservations should be consistent, and
3. concatenation of numerics can be done with by simple math, e.g., (6*10)+0 = 60 or by forcing a string “ “+6+0 = “ 60” (and the first character can easily be removed if desired)

[anon82626866]

i didn’t read all topic, but this is on propulse and it’s 99999% useful with some specific strings. In first picture, if you round the “charac in” (green block), it’ll give a number instead of string, so it’ll show « 6 ».

[ThinBuffalo]

I can certainly see how it’d be useful, and I even addrėssed that in the post that you didn’t entirely read.

My biggest problem is that the addition operator works differently than all the other math blocks. Whether it’s treated as a string or a number should not depend on which math block you use.

IMO, that’s not ok, especially when there’s no documentation that explains the blocks in this level of detail. Are we just supposed to guess how HS has implemented the various blocks? It took me hours to figure out why my code wasn’t working correctly, so I guarantee you there are many other confused users out there.

[qwrt]

yeah; would be nice to have 2 addition blocks, one in the “math” category and another in the “strings” category that both behave differently

[Crosbyman64]

The addition for strings would be called [join (app) and (le)] (a block seen in scratch), which would return “apple”

[Petrichor]

Currently every block will use it as a string if it can.

this will set text to 60 because it converts the second option to a string. The characters between and character at blocks will always return a string and the next block won’t convert it unless it only uses numbers.

It would definitely be more useful if there was a separate concatenation block that converts all its inputs to strings no matter what and an addition block which only uses numbers.

[ThinBuffalo]

Oh, wow. I see now. Petrichor, you get a !

So the implicit conversion logic IS consistent. Still, the implicit conversion is backwards and unintuitive to me.

In Visual Studio, where I have much of my experience;

Msgbox CStr(6) + 0 
// 6

Msgbox “6” + 0
// 6

But after Petrichor’s explanation, I checked out JS since that’s what the HS Player is coded in, and I see that

console.log(‘6’ + 0);
// 60

So I guess my objection was more with JavaScript than with HS

But also in JS

console.log(‘6’ - 0);
// NaN

So HS, in order to prevent a run-time error, then converts the string to a number such that; 6 - 0 // result is 6

This is where HS starts to become difficult to understand to the uninformed. Since in one case (e.g., subtraction) the string is implicitly converted to numeric, while in another (e.g., addition) the string is not converted. Again, it makes sense if you understand JavaScript and understand that HS is layering additional logic on top of JavaScript, but that’s not cool for users without that explicit knowledge.

And then there’s Petrichor’s example of the Max block… where HS introduces a 3rd option(!), converting the numeric to a string… So let’s look at JS again

console.log(Math.max(‘60’,500);
// 500!! Note: HS returns 60

So now there’s 3 options for implicit conversions in HS & in this last case HS is behaving the opposite of JavaScript! Argh. And, again, there’s no documentation that explains any of this. <insert emoji banging head into wall here>

Of course HS is an independent language and the creators can make it work however they like, but as a language that’s supposed to be intuitive and is intended for inexperienced users, I think the handling of datatypes leaves much to be desired.

@AwesomeOnion @Yuanyuan

[t1_hopscotch]

I’ll need to do some more testing, but I’m kind of wondering if an answer would be to have separate bubbles for addition and concatenation operations

(Edit: I had been meaning to write a response myself, and realised that the idea has been mentioned a few times previously — I’d just read and forgotten)

So + would preference numeric addition, and join would preference string concatenation & it’d be a text operator here:

(Scratch has join)

With the behaviour for +, it would try to convert a string to numeric value.

• It would default to 0 for anything invalid, like "apple".
• It would implicitly convert a string like “60” to the number 60

And for join, it would always just concatenate, so you don’t have ambiguity

• e.g. "6" + "0" = "60"

[Crosbyman64]

It would be great in terms of code efficiency. I’m always trying to find ways to reduce code related blocks as much as possible, without losing the features I have implemented in my projects before.