arrow function syntax simplified

[Claus Reinke]

>> To me, the ability to emulate the feature additions so closely in
>> library functions suggests that some variation of fn and rec should go 
>> into the standard library instead of adding such features to arrow 
>> functions.
> 
> Why wouldn't we add arrows too? There's a usability and an 
> efficiency/easier-optimizability case for them even with fn and rec.

I definitely want arrows, and I want them to be efficient enough that
performance is not an obstacle to using them a lot (is mutability a 
problem for function call optimization?). fn and rec are just examples 
of how combining simple features can be as expressive as complex 
features.

Or do you mean adding self- and this-naming to arrows? If it doesn't
hurt, I'm not against - I would just like to see a good case for how
that would be an improvement.

>> But perhaps there are reasons for
>> preferring the language features over the library functions? 
> 
> Your point about synthesizing dynamic-|this| given lexical-|this| forms 
> is good. It seems to me having fn, rec, and => is therefore best. What 
> am I missing?

That is my current state of thinking, too.
 
> I do suspect people won't grok fn and rec, at least not with those 
> names. They're very ML-ish or LISPy, not camelCaps JS-y.

fn was a nod to the earlier "use fn" proposal, and rec seemed
friendlier than y or fix:-) Also, both are short, rec suggests recursion
and fn suggests short function. Yes, probably influenced by ML, but 
that isn't a bad precedent. But I'm not stuck on the names.

Claus