Re: [RFC]Discuss] Syntax for Arrow Functions

On Tue, May 30, 2017 at 3:37 PM, Björn Larsson <bjorn.x.larsson@telia.com> wrote: > Den 2017-05-30 kl. 21:40, skrev Derick Rethans: > >> On Tue, 30 May 2017, Levi Morrison wrote: >> >>> Internals, >>> >>> The previous discussion thread has died down significantly and so I'd >>> like to start a new one to refocus. This message has some redundant >>> information by design so people don't have to reference the other >>> thread so much. >>> >>> Based on the discussion there are a few different syntax choices >>> people liked. Overall it's a feature that people seem to want but >>> everyone seems to prefer a different syntax choice. >>> >>> 1. fn(params) => expr >>> 2. function(params) => expr >>> >>> 3. (params) ==> expr >>> 4. (params) => expr >>> >>> Note that 3 and 4 require a more powerful grammar and parser and that >>> 4 has ambiguities. I think we can work around them by rules -- only >>> mentioning it because its popular because of JavaScript and do not >>> prefer this at all. >>> >>> Note that 1 requires a new keyword. >>> >>> Option 2 looks the best from that perspective but is by far the >>> longest; remember people are partially interested in this feature >>> because they want shorter closures which this doesn't really help. >>> >>> This is why everyone is so divisive. All options have drawbacks. >>> Additionally some people don't like binding by value and would prefer >>> ref, and others really would be against by-ref. >>> >>> Which brings me to an option I don't think was ever discussed on list: >>> >>> 5. >>> [](params) => expr // binds no values >>> [=](params) => expr // binds by value >>> [&](params) => expr // binds by reference >>> >>> It has quite a few good qualities: >>> >>> - No new keywords >>> - Can choose between reference and value >>> - Concise >>> - Has precedence in C++, a major language >>> - Can be done in our existing grammar and parser[1] >>> - Can be extended to allow explicit binding of variables: >>> // all equivalent >>> // y is bound by value, array by reference >>> [&, $y]($x) => $array[] = $x + $y >>> [=, &$array]($x) => $array[] = $x + $y >>> >>> And of course it does have downsides: >>> >>> - Symbol soup (it uses a lot of symbols) >>> - A minor BC break. Empty arrays which are invoked as functions are >>> currently guaranteed to be errors at runtime and would have a new >>> valid meaning. Here's an example from inside an array literal: >>> >>> // error at runtime previously >>> [ []($x) => $x ] >>> // now an array with one item which is a closure that returns >>> its parameter >>> >>> Sara pointed out that we'd need to keep a leading >>> = or & in the >>> array to disambiguate from our array closure form. >>> >>> Overall I'd prefer 1 or 5. What do you guys think? >> >> I think 5 is terrible from a readability point of view. As you said it: >> "symbol soup". > > Do you think having ==> instead of => would make it less of a > symbolic soup? If something is already symbol soup how does adding another symbol make it less so?