The workaround:
?
It works same as: all but first of [list] block.
shouldnt this be in Tutorials (Here's how to...) ?
Sorry!
Fixed
Cool, but why not just use that?
maybe as a challenge? though i guess it wouldn't be very challenging if the workaround is so simple
or maybe the devvelopers (aka jens) could add this in the definiton to all but first of $list (thanks @tethrarxitet)
Use $list $list for list inputs
Give me an moment
all but first of (list [1] [2] @delInput@addInput
[sb]all but first of (list [1] [2] @delInput@addInput[/sb]
that's not a definition. also literally whats the point of this topic? just use delete (1 v) of @list .
No! Boo! The point of ALL BUT FIRST OF is to support functional programming on lists, in which you don't mutate your inputs, but instead return a new list. All of the list-valued 
, 
, etc., functions work this way: they report new lists, and don't mutate their input.
There are always lots of ways to write list programs, but the point of ALL BUT FIRST OF is to support this way:
Yes, this can be done with MAP, but traditionally, in Lisp, MAP isn't a primitive (as it wasn't in BYOB) but is instead implemented recursively:
And of course MAP doesn't work if your data structure is a tree rather than a sequence, or if, say, you want to operate on the items two at a time:
As for @gamercreepernoob's point, it's often true that a Snap! primitive block could be implemented using other Snap! blocks, as in my definition of MAP above. But I agree that we should add that to the EDITable version of ALL BUT FIRST OF.
{(all but first of (input ⋮) :: list)} :: define+
script variables ((inp)) @delInput@addInput
set [inp V] to (split ([json V] of (input) :: operators) by [json v] :: operators)
delete (1) of (inp)
report (inp
trust me, I never use delete (1 v) of @list . but I mean A better workaround is just to
Good idea! And some nice suggestions in this thread. I think if I'd supply a fallback method for all but first of I'd probably do some hyper version, something like:
I guess the whole point about all but first of is that you use it recursively on linked lists, but ... yeah, I like the suggestion to maybe supply some alternative.
what I'm wondering about jointwo @list::lists reporter is why not just
I mean, aren't primitives implemented in snap supposed to show how lots of snap is writable in snap? I feel like removing the whole thing where a completely seperate list is created as a linked list defeats the whole purpose.
it was literally said in the sentence before the image
yeah-and I read it
, and you can using map:
, I don't understand what bh was saying.