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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
