| A few points about proposed syntax for extra [] args: 1. First-time users of the language have to be told about _ . It is a necessary onion. 2. Having two arguments for [...] is about as big a win as having just one. Unary and binary fn's are really common, but higher arities aren't. Also, with a two-argument [..], you can do compositions and such in a much more straightforward and readable way. 3. If you're going to have a systematic naming convention -- $1 $2 $3 -- you wind up with either CL-ish duplication of the (fn) form's role, or some kind of arbitrary cutoff where $(n-1) is OK but $n is verboten. So I propose the following:
[foo _] => (fn (_) (foo _)) [_ 'bar []] => (fn (_ []) (_ 'bar []))
This is good because:1. Currently [] returns the always-nil function, which you also get with [nil]. Waste! 2. Good compression -- no more characters spent on funargs. 3. Don't have to spend any more characters, and no ugly doubling like __. 3. [] looks like it means "nonce". See the second sexpr in http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme-Z-H-15.html#node_sec_13.1 4. Having [..] work for just {0, 1, 2} arguments isn't much more arbitrary than having it work for just {0, 1}, and your cognitive load is reduced because you can choose between fn and [..] autonomically. I'm more than half inclined to think this will turn out to be a stupid idea, but it also feels a little bit elegant (we need one unique symbol, we have one redundancy, and we are prevented from going any further so the syntax stays simple). I don't know enough about the PLT reader to implement this myself and don't have time to learn, so I've got to rely on you folks to find out. What do you think? | 
