I thought about using numbers like that too, but when I posted this I was too tired to remember why that might be a better idea. You're right - it would make more sense to use numbers, and if you're writing a function that's long enough that numbers would make it hard to read, use fn. Zero-indexed numbers with sigils to designate the place in the arg list are better.
([- $1 $2 $0] 1 3 2])
translates to
((fn ($0 $1 $2)
(- $1 $2 $0)) 1 3 2))
I don't like binding the sigil by itself to the second arg - it's starting to look like Perl. I'd even be in favor of eliminating the underscore and only using the sigil-number notation, with the special case that the sigil by itself is arg 0.
(By the way, mathematica is all s-expressions (or rather, equivalently, McCarthy's m-expressions) underneath. You can call FullForm on any expression to strip away the syntactic sugar, eg, FullForm[a+b] => Plus[a,b]. Note the f[a,b] instead of (f a b). A nice thing about the commas is that you can throw in infix wherever it's convenient, like If[x>2+2, B, b] instead of If[Greater[x,Plus[2,2]], B, b]. The best lisp solution I've seen for that is curly sweet-expressions:
http://www.dwheeler.com/readable/
)
Adding parens to make it more "lispy"? I don't see the point, really. Also, why are you passing it a quoted list instead of the actual values you want?
Because this actually works in the current version of Arc. Maybe not quite as concise as the proposed syntax, but probably as close as you can get without adding syntax (at least that I can think of).
So you need to weigh the cost of adding more syntax to the language for the savings of "$1" vs. "(_ 1)".
Note that the latter is more than twice the size of the former, and that you'd also need to put the arguments to [] into a list prior to passing them into the fn. I'd say $1 is a pretty big win in terms of conciseness.
