using (split ([json V] of $list) by [json v]) would be very slow on huge lists, instead use ([id V] of ())
Gosh, Jens, why do you have to have that ugly IF in there?
Yeah, you're right, I keep forgetting about that INDEX feature. It doesn't feel like MAPping to me! I mean, the reason MAP is such a common abstraction is that there are so many cases in which you want to apply a function to each list item, without caring about what order they're in. And JOINTWO isn't like that, so it doesn't feel like a MAP to me.
When we're talking about linked lists, ALL BUT FIRST OF is one of the fundamental operations on pairs (make a pair, left half of pair, right half of pair) out of which everything else is built. From that perspective it makes sense for ALL BUT FIRST OF to be presented as an irreducible primitive, or rather, if you think of a pair as an array of length two, to use ITEM 2 OF as its editable form. But that would be really confusing in the context of Snap!, in which users aren't supposed to think about how we represent lists; that happens below the abstraction barrier. So users would interpret ITEM 2 OF to mean that we were implementing SECOND ITEM OF rather than ALL BUT FIRST OF.
I think it's clearer just to show users
which they'll understand as giving the right answer to ALL BUT FIRST, never mind how lists are implemented.
P.S. If we wanted a totally correct representation of how ALL BUT FIRST works on linked lists, it'd be important to show that it doesn't make a copy, but in fact reports a list that shares the pairs of the input list. This matters to people who think about timing, because ALL BUT FIRST is constant time, not linear time, on linked lists.
If Snap! were consistently constructed as a core language with a set of standardized extensions (compare Scheme, or C 
), "all but first of" would (I guess) be at the core of the language, and it wouldn't even make sense to define this feature in terms of other features.
Agreed. From an application perspective it's downright annoying.
To repair item of in this respect one would have to rewrite it:
ceterum censeo ... this doesn't solve all of item of 's issues though:
Oh. The reason it behaves that way is that it falls out from the way we handle multi-dimensional arrays. If you have a two-dimensional matrix or table, for example,
will select rows 2 and 3, columns 5 and 7 of the array.
will select columns 5 and 7 of all rows of the array; an empty list means not to restrict the selection in that dimension.
But I do understand that interpreting an altogether empty list as selecting the entire array can be confusing -- for example, I didn't realize it'd do that in this (implementing ALL BUT FIRST) context. Perhaps we should special-case an entirely empty index list to report an empty list.
I reject considering this a problem. We don't support numeric keys in dictionaries. This allows us to make ITEM maximally useful.
We, in fact, have decided on the exact opposite, we special case the empty list to serve as a placeholder for the entire one! Geez. I love the short-lived memory in these forums NOT.
but what is the reason for this? can I please see any practical examples?
look, I'm not trying to be rude or anything, but @bh was talking about something different:
it's the same thing, Brian understands about consistency and recursive functions.
he said item (list (list @addInput) (list [1][3] @delInput@addInput)@delInput@addInput) of @list should stay the same, but item (list @addInput) of @list should report list @addInput , because this will not be used to find columns of a list since you should be using 
for the purpose of
to get all of a list. What am misunderstanding?
You're totally annoying me. I'm closing this.
Jens, you're being unfair, to me as well as to @sathvikrias. If you go back and read the messages before yours, you'll see that I already said what you said about the meaning of an empty list as one item of an index list, namely, not to restrict the selection in that dimension:
So your snide
was entirely wrong and unfair.
I do forget things sometimes, but I didn't forget anything this time.
You then quoted me:
But you didn't bother reading what it actually says.
The use of an empty list as one item of an index list is super useful. But the use of an empty list as the entire index list doesn't currently do anything useful; it just reports its (second) input as is. Also, despite your comment about "consistency and recursive functions," I don't see how ITEM can handle multi-dimensional index lists by recursing on the number of dimensions. If you start by applying the first item of the index list to the topmost dimension, the resulting list has the same rank as the input list, not one less. The way to specify that you want to keep all items of the data list would be 
, not an empty list.
For a multi-dimensional array, it wouldn't mean anything for an empty sublist to eliminate all items of the corresponding dimension. You can't have a dimension of length zero. APL returns an empty list for
5 0 5 ⍴ ⍳50
(It has a shape of 5 0 5, but no items.)
( 5 0 5 ⍴ ⍳50 )[1]
RANK ERROR
(5 0 5⍴⍳50)[1]
∧
So it makes sense to use an empty sublist of an index list to mean to keep all the items along that dimension. But that's not what an entirely empty index list means. For APL ITEM it's just an error:
⍳10[]
RANK ERROR
⍳10[]
∧
⍳10[⍳0]
RANK ERROR
⍳10[⍳0]
∧
but, interestingly, for RESHAPE it means to make an array of zero dimensions, i.e., a scalar:
(⍳0) ⍴ ⍳50
1
So as I said, we are free to special-case an entirely empty index list however we want, and I propose that having it report an empty list would be useful, precisely for this case of a NUMBERS FROM whose starting value is greater than its ending value.
Once you calm down and actually read the thread, you can reject that idea, but you're not allowed to accuse me or @sathvikrias of forgetting or misunderstanding anything, when it's you who misunderstood.
thank you.
sadly you don't understand the recursive nature of item of.
