# Different colour (or any other hint) for different data types like text and numbers?

I wanted to switch to a custome based on the letter of a text. But it didn;t work and I didn;t know why. The operation said 97 (as in picture) and there was a custume with the name 97. I tried the join operator and it seems it created a text out of the number 97 and now it suddenly worked.
Seems clear now. After I it got solved, but I spent a lot of time.

So my question is, if the call out, which shows the result of an operation, could have a kind of indicator of the data type or if some blocks - like the "Switch to costume"-Block in this case - could return some more errors.
The operation now looks like it always produces the same result (97), even it means something totally different (a number in upper case and a string the other)

Or do you think that it should work like this?
And I am just too picky?
I am afraid other students could fall in similar traps.

In almost all cases, Snap! converts between numbers and strings invisibly. It's just the case of using a number as the name of a costume that's problematic, and that's because the correct behavior is ambiguous, if the number-name is ≤ the number of costumes.

You're not the only one to have fallen into this trap, so we should do something about it, but I'm not sure what. We could

1. Reject numbers as costume names.
2. Interpret numbers in Switch To Costume as strings if > # of costumes.
3. Interpret numbers as strings if any costume has a numeric name (maybe giving an error if you switch to a costume number that exists).

Number 2 would be the least disruptive, but it's a little kludgy. What do you think?

All of those seem like they might break existing projects. Are you okay with that? If so, I think having two separate blocks for "switch to costume named xxx" and "switch to costume # xxx" would be best. You can even invent that second block using "next costume" in a REPEAT loop.

(Replying because this is a thing that's bitten me in the past as well. )

1 Like

Ah yes, I didn't think of that solution, but I agree it's non-kludgy and puts the user in control.

Well I think, it would not have been so frustrating, if I had know this forum already 2 months ago. It is not an issue to get stuck, if there is place to get helped by kind people. Its not urgent for me, I just want to prevent other students to fall into this trap.

I personally do believe that the "almost all" is one of those things where students run into issues more often than we'd expect/hope, and they tend to be really hard to explain "why". (Because the "why" isn't ideal -- it's an implementation concern, often.)

The other area this happens if stuff like booleans and conditionals where numeric values have explicit meaning because the JS implementation bubbles up.

One potential partial work around is to have functions for type coercion (text () and number () blocks) and then that should force Snap! to use the right type. In the case of the costume blocks, hardmath's is pretty clearly the right fix.

Oh I really hope we can avoid that. A number is, by definition, a word all of whose letters are digits. There really shouldn't be any reason for our users to think otherwise.

Costume names and numbers are the only place I know of where this is broken in Snap!. When users want to preserve leading zeros, they do need to be careful not to do arithmetic on the number, but that's just something to work out, not a bug.

I agree that Booleans vs. numbers are more iffy, although we now have explicit checks for the (empirically discovered) most common gotchas. Jens doesn't like to do type checking because it slows things down, but sometimes the users rebel and then that particular case gets a runtime check.

The really controversial thing that I want is to not treat an empty slot as zero (so that we reserve emptiness for implicit argument slots).

Hi,
But I think Brian #2 proposal is fine

And this does not break anything. Number (costume order) is the priority (as current behavior) and if that have not sense (a number out of the range) it will use the name.

The trouble is, if people use numbers as costume names, the overwhelmingly likely reason is that they're making digit costumes to stamp a number. And so the numbers will typically be small, and so #2 won't really help.

I guess people could start their number names at 100 and use (___ + 100) to compute the costume name in their program. But they'd have to learn to do that.

1 Like

Yes, I know this.

But I only say that your proposal does not break anything

This proposal does not the key for everything, but it will fix some cases (like the reported "97") and it keeps the current behavior when that string could be a number of costume.

So, it's only a little improvement, fixing the problem when we call a name (that really exists) and it does nothing.

I don’t like more magic and conditions. A rule like that just doesn’t feel discoverable and seems like something that’s liable to have a bug. Some student will run into a condition and no teacher will be able to explain why the costume block suddenly behaves differently.

There is another solution, though I still like Hardmath's.

We could work on figuring out how to make this easier, but I'm glad this works. It's quite clear, if not a bit verbose.

IMO, given that this works if there is a number that matches a costume name -- we should always just switch to that costume.

With respect to breaking existing projects, perhaps the right solution is to deprecate the existing blockspec so that it no longer appears in the palette, but still works if loaded from an existing project. The new "switch to costume named __" and "switch to costume # ___" blocks would have separate blockspecs, and no new projects would be broken. (Scratch took this approach when migrating to 2.0 and removing certain blocks while maintaining 1.4 compatibility.)

We've done it before in Snap! - with booleans.
A related option is to add a new input to the spec. switch to costume %type %dropdown and %type can be either [name, number], and then that could update the dropdown on the right to either be costume name or the default item index dropdown that has 1, last, random as options.

We could then soft-deprecate the old behavior by opening existing projects with an "empty" input for type and preserving the current behavior of guessing. It also wouldn't add a block, and new projects could just default to the "name" option to have the same behavior as now.

I still think we could get away with always deferring to the costume name, if the input matches a costume of that name, and requiring people to get the costume number some other way. (How often do people need to go to the Nth costume, but can't reference it by name? The next costume I see as being useful, but that's already there.)