Yeah the point is you'd have to build them out of IN FRONT OF with no LIST function.
This is all really cool! Definitely something I didn’t expect!
Awsome update!
I did experience a limitation of this glorious new alphanumeric indices for lists feature: it can’t of course be used if the search key is a number (at least if it’s a positive integer; I didn’t try -3 or 2.5 and the like), since ITEM {number} OF {list} would, as before, be interpreted as "the i-th element of the list". In such cases using ASSOC is still the way to go … unless there is a trick so as to force Snap! into interpreting a number in ITEM {number} OF as a search key rather than as an ordinal number (?)
you could just put a bit of text at the start or end of the number (preferably something that can't be confused with something else), so "3;" "8;"
@sarpnt: I suppose I could insert a "#" or something in front of any number, thanks for the suggestion.
Still (@bh) I'd rather use a prefix only with the item number, of course, since that takes just 1 operation (vs. {length of list}).
Moreover, to be honest, all things considered ... I have some reservations about the function extension of 
. As now defined, it does two fundamentally different things depending on the type of the first operand. You could call this polymorphism, or cutting corners ... A separate primitive (such as a blazing fast version of good old 
) would be "cleaner", albeit at the price of introducing another Snap! primitive.
Well now that it’s 8.1.5 what’s new?
I already see a new hat block I think
Info on releases still at the same place 
Depends how you look at it. Think "content addressable memory"; then the non-numeric index really is an index.
But also, the hot use case for this feature is importing a csv table and then using the first row to provide item names for the columns. So instead of ITEM 27 OF FOO, which is fragile when whoever posted the csv adds a column next year, you say ITEM ( () NICKNAME) OF FOO and that still works when they rearrange things. (Just this happened to BJC; there was a table of models of automobile that we used as an example and then some government bureaucrat decided to rearrange the columns just to annoy us.)
I’m not questioning the case for having a function that will use the first item of a list as its index. After all, that’s exactly what the aforementioned 
does (even if it has its own limitations). Nor am I disputing the substantial improvements the new feature of 
briings, relative to the existing implementation of .
What I do have doubts about is whether it’s “clean” (from a sort of language-architectural point of view) to have one function () behave very differently if the item designation is a number vs, if it is anything else,
Yeah, I do see what you mean. Mostly we don't worry about formal cleanliness, but we do worry about whether users will understand how to use features. List items actually do have a numeric index in addition to any tag-index you give them, so things like FOR EACH ITEM will work same as ever.
I believe JS and Python both allow non-numeric indices, which is some evidence that users can understand the idea.
I don't yet fully understand how ITEM will work with lists of lists with non-numeric indices in both directions. I still have to play with that.
I don't know enough about JS to answer that part, but in Python you cannot index a list nor a tuple (nor any other such ordered iterable, unless it's a user-made class that allows it) with anything other than an int or a slice ([...][a:b]-like)--e.g., ['a', 'b', 'c']['a'] raises a TypeError:
TypeError: list indices must be integers or slices, not str
In the case of dicts, they're unordered, so you can't use ints as indexes unless the dict has them as keys, like {'a':'b', 1:'4'}.
From that point of view it seems obvious that other primitive functions working with item number, such as 
, 
, and 
should behave accordingly with non-numeric indices. Of these I found only to do what a (naïve) user would expect it do do.
Consider the following script:
This is what it yields:
I don’t even know where to begin to point out the weirdness of this result.
I honestly don’t know how and should behave with non-numeric indices. Just not like this. And perhaps there is no such thing as obvious behavior for these functions with non-numeric indices.
there is no such thing as inserting stuff to a hashtable
the replace behaviour is normal,you use it like the way you use "a[b]=c"
That shouldn't be the case; the whole point of a hash table is that insertion and lookup are both O(n) time.
PS But what's implemented in Snap! aren't hashtables; they're plain old a-lists.
Okay, I'll take it up with the management.
Mgmt here 
Dunno, but this example doesn't look strange to me at all. The rule is very straightforward and does not break any aspect of legacy uses in existing projects:
If you use a numerical index - as is suggested by the oval input slot - it's a numerical index, just like it always has been. if you use anything else that is not a number it is not used as index but instead as a key in an equality dictionary.
That's it. Don't fret about the language. Of course the words "insert" and "replace" don't fit, we know. Both those blocks end up doing the exact same thing when used with non-numerical indices: They associate a value with a key, and in doing so make sure the key is unique. And no, keys and indices are not and never will be the same, nor will it make sense to use them interchangeably, just as using linked and arrayed lists interchangeably is not good pedagogy.
Why did we do that? 2 Reasons: Because we've been implored by professors and teachers to find a way that lets them teach "objects" and "dictionaries" in Snap without having to use a library, and so we can refer to imported data fields by their names instead of counting columns or indices in sub-lists. To me, personally, who cares deeply about objects, the first request isn't even important. Almost nobody gets OOP right, and abusing dictionaries for ad-hoc ADTs or "objects" is as questionable as it has become commonplace. But the other way, the one that lets us explore tables and data sets by their fields and column names is a major step towards making a lot of existing exercises and examples more accessible, by taking away the need for numbers everywhere and instead letting learners use names. Never forget that when kids learn about variables the concept of giving a thing a name is not just powerful, but also a consolation for everyone who has had bad experiences in Maths: CS is their chance to get even with STEM.
If you don't like the new feature, just pretend it's not there. The blocks look the same as always and they can be used the same as always by simply using numbers inside every oval input slot. Just now there's also another way to use them that formerly didn't do anything at all.
Thanks for your elaborate response. I may want to use the (blazing fast, compared with ) functional extension of , and perhaps , but none of the other extended functions, as I don’t get why they do what they do with non-numeric keys; so, of course, I may as well pretend these features aren’t there.
Still - and I’m adding this because I’m genuinely enthusiastic about Snap! as an educational language (and possibly more), and would like it to be embraced by many more users - there remain a few aspects of the whole thing puzzling me:
- the key-operated feature (for lack of a better description) of (and several other runctions) works with all data types as keys except numeric values; this strikes me as rather unusual;
- the key-operated feature of not only inserts data but also replaces existing data from the relevant item in the list (like “4” in the script in post 53);
- the key-operated feature of causes the item that it’s applied on to move to the last position within the list (see again the script in post 53); and if there are several items with the same key (which should never happen, of course) all of them will be replaced by a single item;
- “Of course the words "insert" and "replace" don't fit, we know” (@jens, post 56) - IMO that’s an issue in itself if “we do worry whether users will understand how to use features” (@bh, post 52).
This has been my final critical post regarding this issue; I wouldn’t want to solicit any more response from the Snap! team. Consider my remarks food for thought, if you will.
Just a note that this is Scheme orthodoxy; numbers can't be used as symbols.
Perhaps it would be less confusing to users if only one of those blocks accepted non-numeric index inputs? That wouldn't remove functionality, not if they now both do the same thing. Qw23's comment suggests that REPLACE should take keys and INSERT not. I wouldn't suggest this if, for example, REPLACE worked only if the key was already there and/or INSERT only if it wasn't already there.
Maybe that means "replacing" for me?
oh right