[RFC]Discuss] Syntax for Arrow Functions

Den 2017-05-30 kl. 19:58, skrev Levi Morrison:

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. => expr // binds no values
   = => expr // binds by value
   & => 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 => $array[] = $x + $y
  =, &$array => $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 ]
  // 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?

[1]: I'm pretty sure it can be done but until it's done I can't say
so confidently because sometimes there are things lurking in our
grammar I forget about.

As I said in the old thread, option 5 with ==> instead of => might
be an option. I think that would mitigate the minor BC break.

r//Björn

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. => expr // binds no values
   = => expr // binds by value
   & => 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 => $array[] = $x + $y
  =, &$array => $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 ]
  // 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".

For a similar reason, I would discount 1 as being too vague. And hence
would prefer 2, but I'm not actually convinced about this feature at
all.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php
twitter: @derickr and @xdebug

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.

I was just pondering alternative approaches to stop the => token being ambiguous, and wondered if surrounding the whole expression with braces could work:

{ => $bound * 2 }
{ $a, $b => $a * $b }

I believe this eliminates the ambiguity with array notation, and is more concise than pretty much every alternative. I'm my opinion, grouping the arguments and body would make it more readable in context, as well.

The only potential difficulty with parsing would be that this would technically be valid:

if ( $test ) { $a => $a * 5 };

Because it means this:

if ( $test ) { function ($a) { return $a * 5; }; }

It's not ambiguous, but I don't know if this and similar constructs would cause problems with backtracking in the parser. Worst case, they could probably be defined as illegal, since it's pretty hard to construct a use case for such a thing.

Regards,

--
Rowan Collins
[IMSoP]

My preferences: 1, 3, 4, 5, (big void),  2.
I actually like 4 the most but I get that that might not be practical if it leads to unexpected behaviour.

I can’t think of a scenario where capturing by reference would be helpful in a single line closure. 5 just adds additional complexity with no additional benefit IMHO.

Also, in response to Rowan, a Ruby-style syntax should be possible though:

{|param| expr}

Only caveat is that the || would be required if there are no parameters:

{|| expr}

Levi has mentioned this one before. You could even omit the braces here.

Ilija

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:

=> expr // binds no values
= => expr // binds by value
& => 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 => $array[] = $x + $y
  =, &$array => $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 ]
// 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?

[1]: I'm pretty sure it can be done but until it's done I can't say
so confidently because sometimes there are things lurking in our
grammar I forget about.

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

=> expr // binds no values
= => expr // binds by value
& => expr // binds by reference

As a userland developer, I've been waiting/hoping for short arrow
functions for a long time!

Option 3 seems like the most obvious choice, since that's the
same syntax Hack uses. Would it be very difficult to implement the
parser changes necessary for this syntax? Or is there some other
downside to a more powerful grammar/parser (e.g. worse performance)?

If option 3 isn't viable, my next preference would be option 1.
Presumably the drawback of a new symbol is that it might break
existing code using fn as the name of a class or function.
However, using a new symbol would arguably enable more readable
code than the other options.

Option 2 is not only lengthy, but it also could be confusing
since it reuses the function symbol for something that isn't
a normal function.

Option 5 seems overly complex and hard to read.

Whether option 1, 2, or 3 is used, to me it seems that capturing by
reference would be the most useful and intuitive behavior. It's
intuitive since implicit capture makes it feel like all the captured
variables are in the same scope.

Den 2017-05-31 kl. 00:26, skrev Levi Morrison:

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:

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?

For me it was about using a symbol that is not used for
other things like arrays. Kind of a new ingredience to the
soup ;-)

Not sure at all about the syntax, but going from Sara's
example earlier.

1. [=> $x] a bit similar to [($x)=> $x]
   vs
2. [==> $x] less similar to [($x)=> $x]

2 has in my eyes less soup factor...

Cheers //Björn

Of the proposed options, I'd prefer the double fat-arrow ==>

However, I remain of the opinion that all of those syntaxes are
work-arounds to ambiguity concerns for cases that likely don't actually
occur in real-world codebases.

I don't understand the motivation to design or optimize based on some
theoretical concerns - I'd strongly prefer we do the obvious thing, which,
as I see it, would be to do what most languages do, e.g. the familiar fat
arrow => syntax.

If we're going to provide a closure feature that works more like what you'd
typically find in other languages, we should try to also make it look like
it does in most other languages.

It was said of the generics syntax that I proposed that it would have
ambiguity issues, that it would be impossible (or very difficult) to
implement, but someone actually went an implemented it. I'm generally a bit
skeptical of people who cry "impossible" before giving it their best effort.

Inventing unfamiliar syntax for familiar features should be a painful last
resort, if there is no other choice.

Just my opinion.

I'd love to have this feature, but I'd prefer we don't introduce anymore
"muck" if it's at all avoidable.

On Mon, Jun 5, 2017 at 3:10 PM, Björn Larsson bjorn.x.larsson@telia.com
wrote:

Den 2017-06-01 kl. 18:58, skrev Theodore Brown:

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

=> expr // binds no values
= => expr // binds by value
& => expr // binds by reference

3 > 4 > 1.

2 is not even worth considering and I'd almost prefer not having arrow
functions if their syntax is going to be that self-defeating.

I also see no reason to include both by-value and by-reference binding
Arrow functions are for trivially simple cases where the extra ceremony
of an anonymous function is a waste. If you need to do something
non-trivial, use a full-on anonymous function as we already support.

I want to reiterate that, from a user-POV, arrow functions are barely
functions. It's a case for applying an expression to a set. In most
cases I don't "think about it" as a function in the first place.

$y = 2;
array_map($arr, ($x)=> $x*$y);

While I know that implementation-wise $x * 2 gets wrapped into a
function, that's not really how I'm mentally thinking about it. I'm
thinking of it more like a single line in a foreach. In my head, it's
an expression, not a function. If I needed to be "thinking about it
like a function", I'd use a more function-esque syntax.

The extra complication of multiple binding styles to think about are
just that: extra complication. If I care, then I should be using an
anonymous function whose use() syntax already lets me control that case.

I wonder if "Arrow functions" is even a misleading name for the feature,
in terms of how it should be used.

--Larry Garfield

However, ($obj) -> $var is valid variable property syntax.

Gosh, we really have support for everything. :D That one is even very
important for stuff like (new A)->f().

How about ~> which I at least cannot think of any place it is used at
all. ~ in binary negation and the only place we use it (I checked the
language parser this time to make sure).

I really dislike the ==> idea. One of the main reasons here is to write
less and it looks too much like => or even >= which I really don't like.

($a, $b) ==> $a >= $b

($a, $b) ~> $a >= $b

--
Richard "Fleshgrinder" Fussenegger

the fn($a, $b) => $a + $b ** $c syntax suddenly becomes an acceptable
compromise.

I have to second that.

I might even propose to shorten it from "fn" to just "f" - the resulting
syntax then resembles a mathematical predicate :-)

I really like your thinking here. +1 for just f.

I am not sure why we would require the fat arrow anymore. We most
probably want some symbol there to separate the return type constraint
from the body, but it could be a single symbol instead of two:

f($x) = $x^3
f(int $x): int = $x^3

We could go full math here! :)

--
Richard "Fleshgrinder" Fussenegger

One reason
(not the only one) for me to advocate ==> syntax is that it's the
same syntax as HACK

I'm not a fan of this logic. Using Hack as a kind of prototyping-ground
for PHP features is fine, but since they don't have the same
decision-making process as us, we should be looking at the result of
their experience, not just following their lead. It may seem a subtle
difference, but to me "because that choice has worked out well in Hack"
is a much stronger argument than "because the small team working on Hack
chose it that way a few years ago".

In this case, there's some reason to question if it has worked out
well in Hack, given that IIRC they had to hack (no pun intended) their
parser to implement it.

Regards,

--
Rowan Collins
[IMSoP]