I didn't want to assume any level of knowledge so I just broke the code down into steps and was waiting to see if you queried any of the steps
As far as highlighting hyperisation going on - I think back to when I first used the + in Python.
If the data is numbers - then + adds them together
But if the data is strings, then it concatenates them! Witchcraft I shouted!!!!!!
So I thought this was ridiculous and that Python should use & for string concatenation but I soon got totally used to it and decided that Python was clever in working out what I wanted without me having to spell it out
So I've managed to perform the same mental approach to hyperblocks - if one of the inputs is a list then the + will add the other input to each value of the list and return a new list.
it's the same block! There is no "normal" and "hyperized" version. If you use an operator on a list it will now "just work" instead of throwing an error (as it used to). That's really the whole secret.
Sorry, I have not expressed myself with enough precision.
I do understand it is the same block, what I am trying to suggest is that the same block can be highlighted differently when it is used on a list. Or would that be too hard to implement?
It is me - being shortsighted both physically and mentally - who should say "I'm soo not worthy"; certainly not you as you did above.
Yes, you absolutely can not know that some value is a list if it is a result of some previous calculations.
But what about the simple cases, such as above with the 'numbers from N to M's block, when you do know that something is a list, at least in these cases it would not be impossible?
No other block changes its appearance based on its inputs, so I think it would require a fundamental Snap! design change - which I think isn't going to happen.
I think the way forward is to just use it until it becomes second nature
...what if your argument nevertheless has a weak spot. You said: "No other block does it" but this is not about any other block, it's about a very special kind of use being applied to a data, similarly to how Jens is by no means just another developer, or, as a kid recently refered to him, 'yet another forum moderator'.
It's about a special sort of usage that can be highlighted by a special sort of developer. Now, counter that, if you can. ;~P
I'm not sure why this ambiguity was introduced. I seriously doubt if there are any benefits of not having any clue as to the expression result - list or scalar.
Isn't this script much more readable?
Your right - there's no benefit of not having a clue but there is benefit in that the hyperblock functions can be achieved without having to add extra blocks to the categories.
Like I said, when I started learning Python and found it treats
var1 + var2
differently depending upon what the data types of var1 and var2 are - I was like - that's not right!
But after a very short period of time - I was fine and very happy with the feature
Now, I'd be fine with more stuff like that in Snap! e.g the + block doing a join if the arguments are strings
Once upon a time, there were people who complained about using the same + notation for integers and floats, and even (horrors!) for integer + float, which requires an implicit conversion. Now we've all learned to think "numbers are numbers."
This is a shiny new feature and you're not used to it yet. That's fair.
But checking for "simple cases" isn't simple, and it is slow. And once users started expecting red plus signs, some non-simple case would come along, and they'd think it can't be a list because the plus sign isn't red. And that would be worse than not having any indication at all.
Anyway, what else could [0 1 2 3 4]+2 mean? Especially in the block notation, where the + block is number-colored rather than list-colored (as it would be if it meant something like concatenation).
