This more of a general question about Snap! rather than a specific problem, so not sure if it belongs here.
To me the command list blocks, always felt a bit odd. They seem to stem more from the way Scratch treats lists as a type of variable, rather than the first-class implementation of lists in Snap. After all, they only work if the list is a variable, so in the context of those blocks, lists are not really first class, as inputting a 'naked' list into them does nothing, the list must be part of a variable.
I'm not suggesting anything should be changed, I just thought it was intersting.
Good point. I'll also add that these blocks are (in my opinion) in-between the list and variable categories. They only work on variables, but also only on variables that are lists.
Wait, what? You can, for example, say DELETE (3) OF (MY (COSTUMES)). If you have a list of lists, you can mutate one of the sublists.
You can even mutate a list to which you have no pointer at all (DELETE (1) OF (LIST A B C)), although that isn't a useful thing to do.
Yes, these blocks are inherited from Scratch, but in their version the list input is a pulldown with names of lists; in our version it's an empty slot into which you can drop an arbitrary list-valued expression.
The mutators are incompatible with functional programming on lists, but that's not the same thing as first-classness. First-classness is all or nothing; it's a general property of a data type, not a property of some specific list in some specific context.
Good point. I meant that you cannot use them on 'naked' lists. I'm not saying they are not useful, they just are different from the rest of the list blocks.
Since 'first class' shouldn't be used in this context, is there are better word?
I would say, "The list mutators seem incompatible with the functional programming style used by the other list blocks." The key words are "functional programming."
But also, it shouldn't be surprising if some blocks seem incompatible in purpose with other blocks. For example, the orange CHANGE (var) BY (number) block constrains the variable input to numeric values, whereas variables otherwise can take on any value. The GO TO blocks are a very different approach to movement from the MOVE and TURN blocks. And so on.
always felt a bit odd. They seem to stem more from the way Scratch treats lists as a type of variable, rather than the first-class implementation of lists in Snap. After all, they only work if the list is a variable, so in the context of those blocks, lists are not really first class, as inputting a 'naked' list into them does nothing, the list must be part of a variable.