Surprisingly, nobody in this thread has suggested that lists/strings in functional position could accept two arguments. This would replace the current cut function. Additionally, negative numbers should mean index from the end, and 0 as second argument could mean "to the end". Here's Python, Ruby, arc1, and lastly my suggested semantics:
The i'th item of s
s[i]
s[i]
(s i)
(s i)
The i'th item of s from the end
s[-i]
s[-i]
(s (- (len s) i))
(s (- i))
The first x items of s
s[:x]
s[0,x]
(cut s 0 x)
(s 0 x)
The last x items of s
s[-x:]
s[-x..-1]
(cut s (- (len s) x))
(s (- x) 0)
The items from position i to the end
s[i:]
s[i .. -1]
(cut s i)
(s i 0)
The items from position i to position j (inclusive)
s[i:j+1]
s[i .. j]
(cut s i (+ 1 j))
(s i (+ 1 j))
The items from position i to position j (exclusive)
s[i:j]
s[i ... j]
(cut s i j)
(s i j)
i items beginning at position j.
s[j:j+i]
s[j,i]
(cut s j (+ i j))
(s j (+ i j))
The items from position i to the end minus the last j items
s[i:-j]
s[i ... -j]
(cut s i (- -1 j))
(s i (- j))
i items beginning at the j'th position from the end
s[-j:-j+i]
s[-j,i]
(cut s (- (len s) j) (+ (- (len s) j) i))
(s (- j) (+ i (- j)))
If the [...] syntax had a notation for passing on all arguments, implicit currying would be less important. Being explicit about the currying has the advantage that you don't have to know the arity of a function to recognize that currying is taking place.
How about allowing (+ 3 7 4 6 3) to be written as:
(let numbers '(4 6 3)
(+ 3 7 . numbers))
Couple this with [...] capturing all arguments in a variable and you get something like this (feel free to come up with a better variable than ^):
Yes, by all means. Here, I was talking about currying, though, so splicing was not a concern.
I'm not quite sure whether @ should be allowed to reuse the list when used at the end, but I believe it would be most correct not to. So (like mentioned several times before) the dot notation means cons, while @ means splice, which is not the same thing, even when used at the end of the surrounding list.
I think that people want comments to have value in them. The best example of why this might get downmodded is if you look at it on the comments page it just looks like +1 without any context. So in that case it looks like a pretty vacuous comment. I think that if you enjoy a submission just upmod it. If you have something to add to the conversation add it.
prn:x should mean [prn (x _)] because x is no different from prn, and may very well be a function. Unless you can statically know the value of x, but statical analysis of variable content does not sound very lispy to me. While it's ok for optimization it is not ok for semantics!
Yes, which also means the @ cannot reuse the lst object in this case, and therefore shouldn't do so when it happens to be at the end either. The dot is a notation for CONS, while @ would require copying the list that is spliced in.
Both . and @ are very useful and would be great to have available in any context.
Number 1 gave me an idea; it would be useful if (is 2 2) returned 2 rather than t. The only edge case seems to be (is nil nil) which must return t and not nil...
