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
Here's another question / comment / bug report (?) regarding an item in the Snap 8.1 New features list:
Shouldn't 
report the same result as 
?
For lists, at least (I am aware that PIPE works on non-list data as well).
E.g. 
reports a list (1 4 9 ... 100), and so does 
.
But it's not always like that.
I tried 
versus
. The PIPE version reports a string: #12345678910, whereas the MAP-version reports a list: (#1 .. #10).
Question: is it a bug, or intended behavior? (and if the latter: why?)
If you load an older version of Snap! you'll see the internals of the pipe command
As you can see - it uses
which ends up as this
So, if you want to map, you need to be explicit
OK, thanks for explaining. And (I didn’t know) the JOIN function literally joins anything that’s within a list, including sublists of any depth.
I find the following a bit worrisome
Yes in one case random is in italics but this isn't good. When thinking about the textual equivalent of a Snap! script we now have to pay attention to italics?
@toontalk : What do you expect from people who think identifiers should be case-sensitive? This is just one more example of giving decorations semantic content. Having said that, the case of "random" as a tag probably won't come up very often in practice. (Well, unless people are making a-lists in which the data are blocks and the keys are strings that label the blocks.)
@qw23 : It's neither a bug nor a feature, but rather two features interacting in unexpected ways. As @cymplecy points out, the old library PIPE does the same thing. It's not a surprise that JOIN joins its inputs! And it's not a surprise that PIPE computes each expression once, giving it the entire data input to PIPE. And it's not a surprise that MAP computes the expression separately for each item of its input. But using JOIN with PIPE and MAP makes a surprise out of the combination. The more expected thing to do would be (PIPE (MAP (JOIN ...) ( )) ...).
Saying that a different way, PIPE isn't meant to be a substitute for MAP. If you want MAP you should ask for it. What PIPE does is a substitute for nested procedure calls. Something that might contribute to user confusion is that in some cases hyperblocks are a substitute for MAP.
We've had a real blizzard of new features lately, large and small. I'm not surprised that users are bumping into unexpected results. With luck that'll settle down as users become familiar with the new features. If a year from now we're still getting the same questions from bunches of users, we'll have to reconsider the UI.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.