arrow function syntax simplified
claus.reinke at talk21.com
Thu Apr 5 01:14:28 PDT 2012
>> 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
> 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
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.
More information about the es-discuss