As rkts said, if you start specifying names of variables, then you aren't really saving many characters. The other problem with some of the suggestions is that you don't get the benefit of omitting the outer parens of an expression:
[car _]
Note that there are no parens in that function. On the other hand, most suggestions about putting the variables at the start reintroduce the parens:
[x y || (list x y)]
It would be better to do this:
[x y || list x y]
One option is to do what K does: parameters are called x, y and z by default:
[list x y z]
It's concise, but not really much different to [list _1 _2 _3] or Clojure's #(list %1 %2 %3).
I like the idea of re-purposing \ as a synonym for 'fn', as in some other languages. Personally, I've never used \ as a single-escape character in any Lisp code I've written, and all instances can be replaced with |...| anyway. But this is still not as concise as [...]
(\(x) (car x))
Perhaps using \ as an infix operator would be better:
(x)\(car x)
Pushing it further:
x\(car x)
x\y\z\(list x y z)
This means you can't use rest arguments with this notation, but then I almost never use rest arguments with anonymous functions, just as I don't use implicit progn (which you can't represent with [...] either). You would have to resort to 'fn' in these situations, which is fine because the language should be optimised for the most common case rather than the general case.
One final observation: almost all Arc functions take either one, two or three arguments, with the last one often being a rest argument. So these are the cases that need to be optimised.
almost all Arc functions take either one, two or three arguments, with the last one often being a rest argument. So these are the cases that need to be optimized
Although the other analysis is insightful, IMO, this is the most important part of your post. Although, I'm not looking to optimize all functions, just those with bodies smaller than about twice the size of the "fn (argument list)" code.
