Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rowan Collins]

On 23 June 2017 19:43:19 BST, Rasmus Schultz  wrote:
>Suffice it to say, I understand your arguments and your point of view,
>I
>just don't agree with it

Indeed, as I say, different people want different things from this proposal, 
and no syntax is going to suit all of them. I think this is important, because 
it means the choice of syntax can never fully be separated from the choice of 
feature set.

 
>I'm a big non-believer in syntax alternatives for the same
>language-features for various use-cases

I have a lot of sympathy for this view, and it tempts me to say "if it ain't 
broke, don't fix it" - if the existing syntax covers all scenarios, why bother 
with a new one at all. I understand that your aim would be to replace the 
existing syntax, and perhaps in the distant future remove it altogether.

However, I would point out that a huge number of programming constructs can be 
considered special cases of others. For instance, every while loop can be 
replaced with if and goto, but not every combination of if and goto can be 
turned into a while loop; so at one logical extreme, we should remove while 
loops from the language as redundant syntax for one special case.

Like most such decisions, it's a question of where you draw the line: in this 
case, whether you think single-expression closures are a sufficiently common 
and distinctive case that they deserve their own syntax. Evidently, you think 
they are not; I have been reasonably convinced by examples people have shown 
that they are.

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

I think there is not much point in carrying on this debate.

Suffice it to say, I understand your arguments and your point of view, I
just don't agree with it - if this new feature produces closures, by my
understanding, it's alternate syntax for producing closures, and does not
constitute a new language feature, but rather an alternative to an existing
feature.

I'm a big non-believer in syntax alternatives for the same
language-features for various use-cases - picking between cosmetic options
slows me down while programming. I prefer languages that are consistent, in
the sense that each feature has a consistent syntax that works for every
use-case - and as such I would be happy with an improved syntax that fully
replaces the old syntax and works better for every use-case, but I would
view specialized alternate syntax, for the same feature, for certain
specific use-cases, as merely inconsistency and a symptom of missing
design. I admire languages with little, consistent syntax and
widely-applicable, highly-generalized features.

I understand if not everyone shares my point of view.


On Wed, Jun 21, 2017 at 11:19 PM, Rowan Collins 
wrote:

> On 21/06/2017 15:04, Rasmus Schultz wrote:
> > > For me (and I am not alone), this feature is NOT a new syntax for
> closures
> >
> > Regardless of why you want it, that's exactly what it is though -
> another way to declare a closure.
> >
> > Even if it has different semantics, the resulting object is still an
> instance of Closure, right?
> >
> > It should pass type-checks, it should support reflection, and so on -
> otherwise, that's even more inconsistency,
> > for no practical reason, and it will lead to an endless list of problems
> which people will solve with even more ugly work-arounds,
> > such as omitting type-hints, etc.
>
> I am perfectly happy for the feature to support all those things.
>
>
> > > If what you are looking for is a replacement syntax for existing
> closures, you will have a completely different set of priorities
> >
> > I am not looking for a replacement syntax, but rather a replacement
> feature.
>
> Then you are looking for something different from me. Again, I don't say
> you are wrong in this, I just don't share that desire, because I don't see
> the need to replace - or supplement - a working feature with a slightly
> different version.
>
>
> > I think the priorities and requirements remain the same, but for
> consistency, and to keep this feature generally useful,
> > this feature should have parity with current Closures in terms of
> capabilities - otherwise it will get in the way rather than help.
>
> Again, this makes sense only given your starting point, which is not the
> same as mine.
>
>
> > Once people see the nicer, shorter syntax, and start to enjoy the more
> natural scoping rules, it's going to be
> > very frustrating to have to back-port to the old function-syntax and add
> use-clauses etc every time the code
> > changes and a single expression doesn't cut it.
>
> I mentioned this in my last e-mail without going into details, because it
> was discussed at length in the past, but perhaps you missed that, or have
> forgotten. In PHP, automatic capture of variables is absolutely not a
> natural scoping rule. Apart from the request super-globals - which many
> modern frameworks deliberately hide away from the user - every single
> variable has to be explicitly declared or imported into every single scope,
> throughout the entire language.
>
> The "use" clause on anonymous functions is not some weird wart for
> implementation purposes, it is the natural companion to the "global" and
> "static" keywords, and the natural consequence of not having a declaration
> to force a variable to be local. In PHP, all variables are local to a
> function by default, unless something explicitly says otherwise; there are
> certainly languages, notably JS, where the opposite is true, but that
> doesn't mean PHP is doing it wrong, or that mixing the two conventions in
> one language would be a good idea.
>
> I am willing to accept single-expression lambdas as an exception to this
> rule only because they are constrained to be short and simple; they read
> like an expression embedded in the outer scope, not a complete function in
> their own right.
>
>
> > A single-expression constraint on this feature would be a strange,
> arbitrary, annoying, unnecessary limitation.
> >
> > We didn't get it right the first time.
>
> I disagree with both of these statements. I don't consider this feature an
> attempt to fix something that went wrong, I consider it a new,
> complimentary, feature, for certain cases. Personally, I could live without
> it, but I have been convinced that it would be a useful short-hand for
> certain coding patterns.
>
>
> If we were to allow multiple-statement automatic-capturing closures, we
> would end up with 3 different ways to declare the same thing; using the
> fn() variant as an example:
>
> 

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Pedro Magalhães]

On Wed, Jun 21, 2017 at 11:19 PM, Rowan Collins 
wrote:
>
> The short form is still constrained to be a single expression, because
> otherwise you can't omit the "return" statement;


For the sake of discussion, Groovy has optional returns where the last
evaluated expression in a closure is returned.
http://groovy-lang.org/semantics.html#_optional_return_keyword
http://groovy-lang.org/style-guide.html#_return_keyword_optional

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rowan Collins]

On 21/06/2017 15:04, Rasmus Schultz wrote:
> > For me (and I am not alone), this feature is NOT a new syntax for 
closures

>
> Regardless of why you want it, that's exactly what it is though - 
another way to declare a closure.

>
> Even if it has different semantics, the resulting object is still an 
instance of Closure, right?

>
> It should pass type-checks, it should support reflection, and so on - 
otherwise, that's even more inconsistency,
> for no practical reason, and it will lead to an endless list of 
problems which people will solve with even more ugly work-arounds,

> such as omitting type-hints, etc.

I am perfectly happy for the feature to support all those things.


> > If what you are looking for is a replacement syntax for existing 
closures, you will have a completely different set of priorities

>
> I am not looking for a replacement syntax, but rather a replacement 
feature.


Then you are looking for something different from me. Again, I don't say 
you are wrong in this, I just don't share that desire, because I don't 
see the need to replace - or supplement - a working feature with a 
slightly different version.



> I think the priorities and requirements remain the same, but for 
consistency, and to keep this feature generally useful,
> this feature should have parity with current Closures in terms of 
capabilities - otherwise it will get in the way rather than help.


Again, this makes sense only given your starting point, which is not the 
same as mine.



> Once people see the nicer, shorter syntax, and start to enjoy the 
more natural scoping rules, it's going to be
> very frustrating to have to back-port to the old function-syntax and 
add use-clauses etc every time the code

> changes and a single expression doesn't cut it.

I mentioned this in my last e-mail without going into details, because 
it was discussed at length in the past, but perhaps you missed that, or 
have forgotten. In PHP, automatic capture of variables is absolutely not 
a natural scoping rule. Apart from the request super-globals - which 
many modern frameworks deliberately hide away from the user - every 
single variable has to be explicitly declared or imported into every 
single scope, throughout the entire language.


The "use" clause on anonymous functions is not some weird wart for 
implementation purposes, it is the natural companion to the "global" and 
"static" keywords, and the natural consequence of not having a 
declaration to force a variable to be local. In PHP, all variables are 
local to a function by default, unless something explicitly says 
otherwise; there are certainly languages, notably JS, where the opposite 
is true, but that doesn't mean PHP is doing it wrong, or that mixing the 
two conventions in one language would be a good idea.


I am willing to accept single-expression lambdas as an exception to this 
rule only because they are constrained to be short and simple; they read 
like an expression embedded in the outer scope, not a complete function 
in their own right.



> A single-expression constraint on this feature would be a strange, 
arbitrary, annoying, unnecessary limitation.

>
> We didn't get it right the first time.

I disagree with both of these statements. I don't consider this feature 
an attempt to fix something that went wrong, I consider it a new, 
complimentary, feature, for certain cases. Personally, I could live 
without it, but I have been convinced that it would be a useful 
short-hand for certain coding patterns.



If we were to allow multiple-statement automatic-capturing closures, we 
would end up with 3 different ways to declare the same thing; using the 
fn() variant as an example:


function($x) use($y) { return $x * $y; } // Long form; explicit return 
and explicit capture

fn($x) => $x * $y; // Short form; implicit return and implicit capture
fn($x) => { return $x * $y; } // Hybrid; explicit return, but implicit 
capture


The short form is still constrained to be a single expression, because 
otherwise you can't omit the "return" statement; we would just have a 
third form that looks a bit like the short form, but isn't. So whatever 
syntax we choose, you won't be able to just add a semicolon and an extra 
line to turn a lambda expression into a function body.


To me, the hybrid form is confusing and redundant; the fully shortened 
form makes certain simple closures considerably more concise, and 
remains reasonably readable. It is sugar for those use cases, just as 
the closure itself could be considered sugar for constructing an 
invokable object with private fields, and just as many other language 
features are sugar for more basic operations.


Regards,
--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

> Once you start getting into multi statement closures, all the weird
syntax elements that are being proposed just make it harder to read and
harder to visually parse.

The same is true for current function syntax. But that's what line-breaks
are for :-)

> Automatically importing variables isn’t “more natural”, unless you think
JavaScript is god’s gift to programmers.

Meh, but it's what web developers are used to.

The two biggest web languages, PHP and JS, you know?

Most other languages don't require you to explicitly import vars into
closures either.


On Wed, Jun 21, 2017 at 5:19 PM, Stephen Reay  wrote:

>
> > On 21 Jun 2017, at 21:04, Rasmus Schultz  wrote:
> >
> > Once people see the nicer, shorter syntax,
>
> For anything but the most basic of closures, the shorter syntax just makes
> it harder to visually identify the logic. For 1 liners like `fn($x) => $x *
> 2` I can agree there is an argument that its easier to read. I don’t
> necessarily agree but I can agree there is an argument to be made.
>
> Once you start getting into multi statement closures, all the weird syntax
> elements that are being proposed just make it harder to read and harder to
> visually parse.
>
>
> > and start to enjoy the more
> > natural scoping rules,
>
> Automatically importing variables isn’t “more natural”, unless you think
> JavaScript is god’s gift to programmers.
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

> For me (and I am not alone), this feature is NOT a new syntax for closures

Regardless of why you want it, that's exactly what it is though - another
way to declare a closure.

Even if it has different semantics, the resulting object is still an
instance of Closure, right?

It should pass type-checks, it should support reflection, and so on -
otherwise, that's even more inconsistency, for no practical reason, and it
will lead to an endless list of problems which people will solve with even
more ugly work-arounds, such as omitting type-hints, etc.

> If what you are looking for is a replacement syntax for existing
closures, you will have a completely different set of priorities

I am not looking for a replacement syntax, but rather a replacement feature.

I think the priorities and requirements remain the same, but for
consistency, and to keep this feature generally useful, this feature should
have parity with current Closures in terms of capabilities - otherwise it
will get in the way rather than help.

Once people see the nicer, shorter syntax, and start to enjoy the more
natural scoping rules, it's going to be very frustrating to have to
back-port to the old function-syntax and add use-clauses etc every time the
code changes and a single expression doesn't cut it.

A single-expression constraint on this feature would be a strange,
arbitrary, annoying, unnecessary limitation.

We didn't get it right the first time. Let's get it right this time, not
just adding another feature as a work-around to certain specific cases.

We have closures - no matter how you view it or describe it, regardless of
why you want this feature, this is another way to create closures, and it
needs to have parity with the existing feature.

Unless you're saying these are an entirely new type of object that isn't an
instance of Closure, in which case I'd say this whole feature is guaranteed
to do considerably more harm than good?


On Tue, Jun 20, 2017 at 7:52 PM, Rowan Collins 
wrote:

> On 19 June 2017 21:22:53 BST, Rasmus Schultz  wrote:
> >So what's on the table is a syntax-improved but feature-crippled
> >variant of
> >closures, not an all-round replacement?
>
> I haven't the time right now to dig out my summary from the mail archives,
> but this is one of the fundamental disagreements / misunderstandings that
> made discussion difficult the first time: different people want very
> different things from this feature, leading to conflicting views on whether
> certain things are advantages or disadvantages.
>
> For me (and I am not alone), this feature is NOT a new syntax for
> closures. It is a new TYPE of closure, with new semantics - automatically
> capturing variables - for a specific use case.
>
> Personally, I am strongly opposed to any multi-line version of it, because
> I don't want the fundamental scoping rules of the language changed except
> for the specific case of simple lambda expressions.
>
> If what you are looking for is a replacement syntax for existing closures,
> you will have a completely different set of priorities. That doesn't make
> either of us wrong, but it does mean we're going to find it very hard to
> agree on a syntax and feature set.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rowan Collins]

On 19 June 2017 21:22:53 BST, Rasmus Schultz  wrote:
>So what's on the table is a syntax-improved but feature-crippled
>variant of
>closures, not an all-round replacement?

I haven't the time right now to dig out my summary from the mail archives, but 
this is one of the fundamental disagreements / misunderstandings that made 
discussion difficult the first time: different people want very different 
things from this feature, leading to conflicting views on whether certain 
things are advantages or disadvantages.

For me (and I am not alone), this feature is NOT a new syntax for closures. It 
is a new TYPE of closure, with new semantics - automatically capturing 
variables - for a specific use case. 

Personally, I am strongly opposed to any multi-line version of it, because I 
don't want the fundamental scoping rules of the language changed except for the 
specific case of simple lambda expressions.

If what you are looking for is a replacement syntax for existing closures, you 
will have a completely different set of priorities. That doesn't make either of 
us wrong, but it does mean we're going to find it very hard to agree on a 
syntax and feature set.

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

> I just think your example is an exaggeration to what happens in practice.

I think it's an example of what happens with any inconsistent feature in
any language.


On Tue, Jun 20, 2017 at 9:53 AM, Markus Fischer  wrote:

> Hello Rasmus,
>
> On 19.06.17 22:22, Rasmus Schultz wrote:
>
>> If I have to factor back and forth between new and old syntax every time a
>> closure changes from one to multiple or back to one statement, then,
>> frankly, what's the point?
>>
>> I think I would just keep using the old syntax, then - for consistency,
>> and
>> to save myself the frustration of factoring back and forth.
>>
>
> I'm writing closures every day and it's so rare to have this changes from
> single/multiple I don't even remember. I think in practice this is a
> non-issue except for very rare special cases and, don't forget: it's
> optional, you don't have to.
>
> In my opinion, if this is worth doing, it's worth doing it right.
>>
>
> No counter-argument here :)
>
> I just think your example is an exaggeration to what happens in practice.
>
> - Markus
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Ilija Tovilo]

Well, the Ruby/Rust syntax would serve us well here too:

$things->forEach(|$v| {
    foo($v);
    bar($v);
});

On 19 Jun, 2017, at 09:43 PM, Rasmus Schultz  wrote:

I actually like this syntax, but what would it look like for multi-statement 
closures?

A nested set of curly braces around the body would look pretty messy.

    $things->forEach({$v => { foo($v); bar($v); }});


On Mon, Jun 19, 2017 at 4:43 PM, Levi Morrison  wrote:
On Sun, Jun 18, 2017 at 1:44 PM, Ilija Tovilo  wrote:

Sorry, I wasn’t aware of that.

What do you think of the Ruby/Rust style syntax that Levi proposed a while back?

$someDict
     ->map(|$v| $v * 2)
     ->filter(|$v| $v % 3);

This one has a few advantages:

1. It has syntax (a lot of) developers are already familiar with
2. It has no ambiguities and is fully backward compatible
3. It’s the shortest of all options available (two `|` characters and one space)


We determined that the arrow between the parameters and the expression
would still be required. Given this limitation I think this syntax is
seviceable:

    $someDict
        ->map({$v => $v * 2})
        ->filter({$v => $v % 3});

Sometime this week I intend to start another thread that narrows us
down to two choices.

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Markus Fischer]

Hello Rasmus,

On 19.06.17 22:22, Rasmus Schultz wrote:

If I have to factor back and forth between new and old syntax every time a
closure changes from one to multiple or back to one statement, then,
frankly, what's the point?

I think I would just keep using the old syntax, then - for consistency, and
to save myself the frustration of factoring back and forth.


I'm writing closures every day and it's so rare to have this changes 
from single/multiple I don't even remember. I think in practice this is 
a non-issue except for very rare special cases and, don't forget: it's 
optional, you don't have to.



In my opinion, if this is worth doing, it's worth doing it right.


No counter-argument here :)

I just think your example is an exaggeration to what happens in practice.

- Markus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

So what's on the table is a syntax-improved but feature-crippled variant of
closures, not an all-round replacement?

If I have to factor back and forth between new and old syntax every time a
closure changes from one to multiple or back to one statement, then,
frankly, what's the point?

I think I would just keep using the old syntax, then - for consistency, and
to save myself the frustration of factoring back and forth.

The old syntax is a burden, but a new feature with limited applicability,
honestly, I think would be even more of a burden.

In my opinion, if this is worth doing, it's worth doing it right.


On Mon, Jun 19, 2017 at 10:12 PM, Larry Garfield 
wrote:

>
>
> On 06/19/2017 03:45 PM, Rasmus Schultz wrote:
>
>> Or maybe it'll look okay if you format the code?
>>
>>  $things->forEach({$v => {
>>  foo($v);
>>  bar($v);
>>  }});
>>
>> Still looks kinda crazy with the closing "}})" though...
>>
>
> Multi-line lambdas should use the existing syntax without changes. The
> only thing being discussed here is single-statement lambdas that you would
> want to inline and think of as an expression rather than a function call.
> If you need something more complex than that just use the existing syntax.
>
> --Larry Garfield
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Larry Garfield]

On 06/19/2017 03:45 PM, Rasmus Schultz wrote:

Or maybe it'll look okay if you format the code?

 $things->forEach({$v => {
 foo($v);
 bar($v);
 }});

Still looks kinda crazy with the closing "}})" though...


Multi-line lambdas should use the existing syntax without changes. The 
only thing being discussed here is single-statement lambdas that you 
would want to inline and think of as an expression rather than a 
function call.  If you need something more complex than that just use 
the existing syntax.


--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

Or maybe it'll look okay if you format the code?

$things->forEach({$v => {
foo($v);
bar($v);
}});

Still looks kinda crazy with the closing "}})" though...


On Mon, Jun 19, 2017 at 9:43 PM, Rasmus Schultz  wrote:

> I actually like this syntax, but what would it look like for
> multi-statement closures?
>
> A nested set of curly braces around the body would look pretty messy.
>
> $things->forEach({$v => { foo($v); bar($v); }});
>
>
> On Mon, Jun 19, 2017 at 4:43 PM, Levi Morrison  wrote:
>
>> On Sun, Jun 18, 2017 at 1:44 PM, Ilija Tovilo 
>> wrote:
>> > Sorry, I wasn’t aware of that.
>> >
>> > What do you think of the Ruby/Rust style syntax that Levi proposed a
>> while back?
>> >
>> > $someDict
>> > ->map(|$v| $v * 2)
>> > ->filter(|$v| $v % 3);
>> >
>> > This one has a few advantages:
>> >
>> > 1. It has syntax (a lot of) developers are already familiar with
>> > 2. It has no ambiguities and is fully backward compatible
>> > 3. It’s the shortest of all options available (two `|` characters and
>> one space)
>>
>> We determined that the arrow between the parameters and the expression
>> would still be required. Given this limitation I think this syntax is
>> seviceable:
>>
>> $someDict
>> ->map({$v => $v * 2})
>> ->filter({$v => $v % 3});
>>
>> Sometime this week I intend to start another thread that narrows us
>> down to two choices.
>>
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

I actually like this syntax, but what would it look like for
multi-statement closures?

A nested set of curly braces around the body would look pretty messy.

$things->forEach({$v => { foo($v); bar($v); }});


On Mon, Jun 19, 2017 at 4:43 PM, Levi Morrison  wrote:

> On Sun, Jun 18, 2017 at 1:44 PM, Ilija Tovilo  wrote:
> > Sorry, I wasn’t aware of that.
> >
> > What do you think of the Ruby/Rust style syntax that Levi proposed a
> while back?
> >
> > $someDict
> > ->map(|$v| $v * 2)
> > ->filter(|$v| $v % 3);
> >
> > This one has a few advantages:
> >
> > 1. It has syntax (a lot of) developers are already familiar with
> > 2. It has no ambiguities and is fully backward compatible
> > 3. It’s the shortest of all options available (two `|` characters and
> one space)
>
> We determined that the arrow between the parameters and the expression
> would still be required. Given this limitation I think this syntax is
> seviceable:
>
> $someDict
> ->map({$v => $v * 2})
> ->filter({$v => $v % 3});
>
> Sometime this week I intend to start another thread that narrows us
> down to two choices.
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Levi Morrison]

On Sun, Jun 18, 2017 at 1:44 PM, Ilija Tovilo  wrote:
> Sorry, I wasn’t aware of that.
>
> What do you think of the Ruby/Rust style syntax that Levi proposed a while 
> back?
>
> $someDict
> ->map(|$v| $v * 2)
> ->filter(|$v| $v % 3);
>
> This one has a few advantages:
>
> 1. It has syntax (a lot of) developers are already familiar with
> 2. It has no ambiguities and is fully backward compatible
> 3. It’s the shortest of all options available (two `|` characters and one 
> space)

We determined that the arrow between the parameters and the expression
would still be required. Given this limitation I think this syntax is
seviceable:

$someDict
->map({$v => $v * 2})
->filter({$v => $v % 3});

Sometime this week I intend to start another thread that narrows us
down to two choices.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Dan Ackroyd]

On 18 June 2017 at 19:48, Rasmus Schultz  wrote:
>
> I was referring to the visual ambiguity - the fn($x) part of the syntax is
> indistinguishable from a function-call.


Only to the same extent that if($x) {} is indistinguishable from a
function call.

Most people don't have a problem with this.

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Ilija Tovilo]

Sorry, I wasn’t aware of that.

What do you think of the Ruby/Rust style syntax that Levi proposed a while back?

$someDict
->map(|$v| $v * 2)
->filter(|$v| $v % 3);

This one has a few advantages:

1. It has syntax (a lot of) developers are already familiar with
2. It has no ambiguities and is fully backward compatible
3. It’s the shortest of all options available (two `|` characters and one space)


> On 18 Jun 2017, at 20:48, Rasmus Schultz  wrote:
> 
> I understand it's not ambiguous to the parser if it's a keyword.
> 
> I was referring to the visual ambiguity - the fn($x) part of the syntax is 
> indistinguishable from a function-call.
> 
> 
> On Sun, Jun 18, 2017 at 8:42 PM, Ilija Tovilo  > wrote:
> > I don't agree that the fn keyword solves the ambiguity problem - it looks
> > exactly like a function call.
> 
> 
> Right. But it does solve the ambiguity if `fn` is a keyword which is what the 
> RFC suggests.
> 
> 
> > On 18 Jun 2017, at 18:40, Rasmus Schultz  > > wrote:
> >
> > I don't agree that the fn keyword solves the ambiguity problem - it looks
> > exactly like a function call.
> >
> > As for the backslash, my honest reaction is, ugh, please, no more
> > backslashes - PHP (and every other language) uses backslashes for escaping
> > in strings, it already looks pretty awkward in namespaces, this won't help.
> >
> >
> > On Sun, Jun 18, 2017 at 12:58 PM, Ilija Tovilo  > > wrote:
> >
> >> The backslash has actually been one of the earlier options if I remember
> >> correctly.
> >> I definitely prefer the `fn` keyword as it’s only one character more but
> >> adds a better visual hint to the arrow function.
> >>
> >> I’m also not sure why we’d choose a different arrow (`==>` or `~>`) when
> >> the ambiguity is solved through either a the backslash or the `fn` keyword.
> >>
> >>
> >>> On 15 Jun 2017, at 17:00, Björn Larsson  >>> >
> >> wrote:
> >>>
> >>> Den 2017-06-15 kl. 15:34, skrev Fleshgrinder:
> >>>
>  On 6/15/2017 3:29 PM, Björn Larsson wrote:
> > Seems like the constraints on this feature makes it hard to fly, i.e.
> > 1. Not a hackish implementation
> > 2. Non ambiguous syntax
> > 3. Easy to parse & use syntax for the human
> >
> > HackLang then prioritised 2 & 3 making the end-users happy, but
> > had to sacrifise a clean implementation. Any clue if this was a one-
> > time effort once it was done or something with a lot of drawbacks
> > in terms of maintenance, performance, evolution etc?
> >
> > r//Björn
> >
>  On Reddit someone proposed the following syntax:
> 
> \() => echo 'Hello, World'
> 
>  It is used by Haskell if I remember correctly and should not be
>  ambiguous since `(` is not allowed in names of classes or functions. It
>  actually aligns well with functions that are called with a
>  fully-qualified name (e.g. `\printf('')`).
> 
>  Not sure if it would still require hacks though.
> 
> >>> So applying that one on Sara's example becomes with some
> >>> options for the arrow:
> >>> 8. $someDict->map(\($v) => $v * 2)->filter(\($v) => $v % 3);
> >>> 9. $someDict->map(\($v) ==> $v * 2)->filter(\($v) ==> $v % 3);
> >>> 10. $someDict->map(\($v) ~> $v * 2)->filter(\($v) ~> $v % 3);
> >>>
> >>> Interesting :)
> >>>
> >>> r//Björn
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List
> >>> To unsubscribe, visit: http://www.php.net/unsub.php 
> >>>  <
> >> http://www.php.net/unsub.php >
> >>
> 
> 

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

I understand it's not ambiguous to the parser if it's a keyword.

I was referring to the visual ambiguity - the fn($x) part of the syntax is
indistinguishable from a function-call.


On Sun, Jun 18, 2017 at 8:42 PM, Ilija Tovilo  wrote:

> > I don't agree that the fn keyword solves the ambiguity problem - it looks
> > exactly like a function call.
>
>
> Right. But it does solve the ambiguity if `fn` is a keyword which is what
> the RFC suggests.
>
>
> > On 18 Jun 2017, at 18:40, Rasmus Schultz  wrote:
> >
> > I don't agree that the fn keyword solves the ambiguity problem - it looks
> > exactly like a function call.
> >
> > As for the backslash, my honest reaction is, ugh, please, no more
> > backslashes - PHP (and every other language) uses backslashes for
> escaping
> > in strings, it already looks pretty awkward in namespaces, this won't
> help.
> >
> >
> > On Sun, Jun 18, 2017 at 12:58 PM, Ilija Tovilo 
> wrote:
> >
> >> The backslash has actually been one of the earlier options if I remember
> >> correctly.
> >> I definitely prefer the `fn` keyword as it’s only one character more but
> >> adds a better visual hint to the arrow function.
> >>
> >> I’m also not sure why we’d choose a different arrow (`==>` or `~>`) when
> >> the ambiguity is solved through either a the backslash or the `fn`
> keyword.
> >>
> >>
> >>> On 15 Jun 2017, at 17:00, Björn Larsson 
> >> wrote:
> >>>
> >>> Den 2017-06-15 kl. 15:34, skrev Fleshgrinder:
> >>>
>  On 6/15/2017 3:29 PM, Björn Larsson wrote:
> > Seems like the constraints on this feature makes it hard to fly, i.e.
> > 1. Not a hackish implementation
> > 2. Non ambiguous syntax
> > 3. Easy to parse & use syntax for the human
> >
> > HackLang then prioritised 2 & 3 making the end-users happy, but
> > had to sacrifise a clean implementation. Any clue if this was a one-
> > time effort once it was done or something with a lot of drawbacks
> > in terms of maintenance, performance, evolution etc?
> >
> > r//Björn
> >
>  On Reddit someone proposed the following syntax:
> 
> \() => echo 'Hello, World'
> 
>  It is used by Haskell if I remember correctly and should not be
>  ambiguous since `(` is not allowed in names of classes or functions.
> It
>  actually aligns well with functions that are called with a
>  fully-qualified name (e.g. `\printf('')`).
> 
>  Not sure if it would still require hacks though.
> 
> >>> So applying that one on Sara's example becomes with some
> >>> options for the arrow:
> >>> 8. $someDict->map(\($v) => $v * 2)->filter(\($v) => $v % 3);
> >>> 9. $someDict->map(\($v) ==> $v * 2)->filter(\($v) ==> $v % 3);
> >>> 10. $someDict->map(\($v) ~> $v * 2)->filter(\($v) ~> $v % 3);
> >>>
> >>> Interesting :)
> >>>
> >>> r//Björn
> >>>
> >>> --
> >>> PHP Internals - PHP Runtime Development Mailing List
> >>> To unsubscribe, visit: http://www.php.net/unsub.php <
> >> http://www.php.net/unsub.php>
> >>
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Ilija Tovilo]

> I don't agree that the fn keyword solves the ambiguity problem - it looks
> exactly like a function call.


Right. But it does solve the ambiguity if `fn` is a keyword which is what the 
RFC suggests.


> On 18 Jun 2017, at 18:40, Rasmus Schultz  wrote:
> 
> I don't agree that the fn keyword solves the ambiguity problem - it looks
> exactly like a function call.
> 
> As for the backslash, my honest reaction is, ugh, please, no more
> backslashes - PHP (and every other language) uses backslashes for escaping
> in strings, it already looks pretty awkward in namespaces, this won't help.
> 
> 
> On Sun, Jun 18, 2017 at 12:58 PM, Ilija Tovilo  wrote:
> 
>> The backslash has actually been one of the earlier options if I remember
>> correctly.
>> I definitely prefer the `fn` keyword as it’s only one character more but
>> adds a better visual hint to the arrow function.
>> 
>> I’m also not sure why we’d choose a different arrow (`==>` or `~>`) when
>> the ambiguity is solved through either a the backslash or the `fn` keyword.
>> 
>> 
>>> On 15 Jun 2017, at 17:00, Björn Larsson 
>> wrote:
>>> 
>>> Den 2017-06-15 kl. 15:34, skrev Fleshgrinder:
>>> 
 On 6/15/2017 3:29 PM, Björn Larsson wrote:
> Seems like the constraints on this feature makes it hard to fly, i.e.
> 1. Not a hackish implementation
> 2. Non ambiguous syntax
> 3. Easy to parse & use syntax for the human
> 
> HackLang then prioritised 2 & 3 making the end-users happy, but
> had to sacrifise a clean implementation. Any clue if this was a one-
> time effort once it was done or something with a lot of drawbacks
> in terms of maintenance, performance, evolution etc?
> 
> r//Björn
> 
 On Reddit someone proposed the following syntax:
 
\() => echo 'Hello, World'
 
 It is used by Haskell if I remember correctly and should not be
 ambiguous since `(` is not allowed in names of classes or functions. It
 actually aligns well with functions that are called with a
 fully-qualified name (e.g. `\printf('')`).
 
 Not sure if it would still require hacks though.
 
>>> So applying that one on Sara's example becomes with some
>>> options for the arrow:
>>> 8. $someDict->map(\($v) => $v * 2)->filter(\($v) => $v % 3);
>>> 9. $someDict->map(\($v) ==> $v * 2)->filter(\($v) ==> $v % 3);
>>> 10. $someDict->map(\($v) ~> $v * 2)->filter(\($v) ~> $v % 3);
>>> 
>>> Interesting :)
>>> 
>>> r//Björn
>>> 
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php <
>> http://www.php.net/unsub.php>
>> 


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

I don't agree that the fn keyword solves the ambiguity problem - it looks
exactly like a function call.

As for the backslash, my honest reaction is, ugh, please, no more
backslashes - PHP (and every other language) uses backslashes for escaping
in strings, it already looks pretty awkward in namespaces, this won't help.


On Sun, Jun 18, 2017 at 12:58 PM, Ilija Tovilo  wrote:

> The backslash has actually been one of the earlier options if I remember
> correctly.
> I definitely prefer the `fn` keyword as it’s only one character more but
> adds a better visual hint to the arrow function.
>
> I’m also not sure why we’d choose a different arrow (`==>` or `~>`) when
> the ambiguity is solved through either a the backslash or the `fn` keyword.
>
>
> > On 15 Jun 2017, at 17:00, Björn Larsson 
> wrote:
> >
> > Den 2017-06-15 kl. 15:34, skrev Fleshgrinder:
> >
> >> On 6/15/2017 3:29 PM, Björn Larsson wrote:
> >>> Seems like the constraints on this feature makes it hard to fly, i.e.
> >>> 1. Not a hackish implementation
> >>> 2. Non ambiguous syntax
> >>> 3. Easy to parse & use syntax for the human
> >>>
> >>> HackLang then prioritised 2 & 3 making the end-users happy, but
> >>> had to sacrifise a clean implementation. Any clue if this was a one-
> >>> time effort once it was done or something with a lot of drawbacks
> >>> in terms of maintenance, performance, evolution etc?
> >>>
> >>> r//Björn
> >>>
> >> On Reddit someone proposed the following syntax:
> >>
> >> \() => echo 'Hello, World'
> >>
> >> It is used by Haskell if I remember correctly and should not be
> >> ambiguous since `(` is not allowed in names of classes or functions. It
> >> actually aligns well with functions that are called with a
> >> fully-qualified name (e.g. `\printf('')`).
> >>
> >> Not sure if it would still require hacks though.
> >>
> > So applying that one on Sara's example becomes with some
> > options for the arrow:
> > 8. $someDict->map(\($v) => $v * 2)->filter(\($v) => $v % 3);
> > 9. $someDict->map(\($v) ==> $v * 2)->filter(\($v) ==> $v % 3);
> > 10. $someDict->map(\($v) ~> $v * 2)->filter(\($v) ~> $v % 3);
> >
> > Interesting :)
> >
> > r//Björn
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php <
> http://www.php.net/unsub.php>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Ilija Tovilo]

The backslash has actually been one of the earlier options if I remember 
correctly.
I definitely prefer the `fn` keyword as it’s only one character more but adds a 
better visual hint to the arrow function.

I’m also not sure why we’d choose a different arrow (`==>` or `~>`) when the 
ambiguity is solved through either a the backslash or the `fn` keyword.


> On 15 Jun 2017, at 17:00, Björn Larsson  wrote:
> 
> Den 2017-06-15 kl. 15:34, skrev Fleshgrinder:
> 
>> On 6/15/2017 3:29 PM, Björn Larsson wrote:
>>> Seems like the constraints on this feature makes it hard to fly, i.e.
>>> 1. Not a hackish implementation
>>> 2. Non ambiguous syntax
>>> 3. Easy to parse & use syntax for the human
>>> 
>>> HackLang then prioritised 2 & 3 making the end-users happy, but
>>> had to sacrifise a clean implementation. Any clue if this was a one-
>>> time effort once it was done or something with a lot of drawbacks
>>> in terms of maintenance, performance, evolution etc?
>>> 
>>> r//Björn
>>> 
>> On Reddit someone proposed the following syntax:
>> 
>> \() => echo 'Hello, World'
>> 
>> It is used by Haskell if I remember correctly and should not be
>> ambiguous since `(` is not allowed in names of classes or functions. It
>> actually aligns well with functions that are called with a
>> fully-qualified name (e.g. `\printf('')`).
>> 
>> Not sure if it would still require hacks though.
>> 
> So applying that one on Sara's example becomes with some
> options for the arrow:
> 8. $someDict->map(\($v) => $v * 2)->filter(\($v) => $v % 3);
> 9. $someDict->map(\($v) ==> $v * 2)->filter(\($v) ==> $v % 3);
> 10. $someDict->map(\($v) ~> $v * 2)->filter(\($v) ~> $v % 3);
> 
> Interesting :)
> 
> r//Björn
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php 
> 

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-15 kl. 15:34, skrev Fleshgrinder:


On 6/15/2017 3:29 PM, Björn Larsson wrote:

Seems like the constraints on this feature makes it hard to fly, i.e.
1. Not a hackish implementation
2. Non ambiguous syntax
3. Easy to parse & use syntax for the human

HackLang then prioritised 2 & 3 making the end-users happy, but
had to sacrifise a clean implementation. Any clue if this was a one-
time effort once it was done or something with a lot of drawbacks
in terms of maintenance, performance, evolution etc?

r//Björn


On Reddit someone proposed the following syntax:

 \() => echo 'Hello, World'

It is used by Haskell if I remember correctly and should not be
ambiguous since `(` is not allowed in names of classes or functions. It
actually aligns well with functions that are called with a
fully-qualified name (e.g. `\printf('')`).

Not sure if it would still require hacks though.


So applying that one on Sara's example becomes with some
options for the arrow:
8. $someDict->map(\($v) => $v * 2)->filter(\($v) => $v % 3);
9. $someDict->map(\($v) ==> $v * 2)->filter(\($v) ==> $v % 3);
10. $someDict->map(\($v) ~> $v * 2)->filter(\($v) ~> $v % 3);

Interesting :)

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Fleshgrinder]

On 6/15/2017 3:29 PM, Björn Larsson wrote:
> Seems like the constraints on this feature makes it hard to fly, i.e.
> 1. Not a hackish implementation
> 2. Non ambiguous syntax
> 3. Easy to parse & use syntax for the human
> 
> HackLang then prioritised 2 & 3 making the end-users happy, but
> had to sacrifise a clean implementation. Any clue if this was a one-
> time effort once it was done or something with a lot of drawbacks
> in terms of maintenance, performance, evolution etc?
> 
> r//Björn
> 

On Reddit someone proposed the following syntax:

\() => echo 'Hello, World'

It is used by Haskell if I remember correctly and should not be
ambiguous since `(` is not allowed in names of classes or functions. It
actually aligns well with functions that are called with a
fully-qualified name (e.g. `\printf('')`).

Not sure if it would still require hacks though.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-10 kl. 10:05, skrev Björn Larsson:


Den 2017-06-09 kl. 15:44, skrev Sara Golemon:
On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson 
 wrote:

If I take the liberty in using the example above on our option list:
1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
2. $someDict->map(function($v) => $v * 2)->filter(function($v) => $v 
% 3);

3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);//
Ambiguous
5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);

Old proposals:
6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v % 3);


Something else which really pops in these examples is the effect of
not needing to use parentheses when embedding a single-arg short
lambda.   3 and 6 in your list read cleaner to me (due to the lack of
parenthesis clutter).  Sadly ~> has the same hacky implementation
issues as ==>, but I think that shows a little bit of why the HackLang
team decided the messy lexer was worth the clearer syntax.


Yup, totally agree on that one. It improves redability and when you have
more parameters I find the parenthesis less disturbing like.
- $someDict->map(($v, $y) ==> $v * 2 + $y)->filter(($v, $y) ==> $v % 3 
- $y);


Btw, do you think there is a way around the hacky implementation, given
that PHP now has a new and shining engine?

r//Björn


Seems like the constraints on this feature makes it hard to fly, i.e.
1. Not a hackish implementation
2. Non ambiguous syntax
3. Easy to parse & use syntax for the human

HackLang then prioritised 2 & 3 making the end-users happy, but
had to sacrifise a clean implementation. Any clue if this was a one-
time effort once it was done or something with a lot of drawbacks
in terms of maintenance, performance, evolution etc?

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Niklas Keller]

2017-06-10 11:09 GMT+02:00 Stephen Reay :

>
> > On 10 Jun 2017, at 15:19, Björn Larsson 
> wrote:
> >
> > Den 2017-06-09 kl. 22:00, skrev Niklas Keller:
> >> 2017-06-09 15:44 GMT+02:00 Sara Golemon :
> >>
> >>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson <
> bjorn.x.lars...@telia.com>
> >>> wrote:
>  If I take the liberty in using the example above on our option list:
>  1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
>  2. $someDict->map(function($v) => $v * 2)->filter(function($v) => $v %
> >>> 3);
>  3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
>  4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);//
>  Ambiguous
>  5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);
> 
>  Old proposals:
>  6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
>  7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v % 3);
> 
> >>> Something else which really pops in these examples is the effect of
> >>> not needing to use parentheses when embedding a single-arg short
> >>> lambda.   3 and 6 in your list read cleaner to me (due to the lack of
> >>> parenthesis clutter).  Sadly ~> has the same hacky implementation
> >>> issues as ==>, but I think that shows a little bit of why the HackLang
> >>> team decided the messy lexer was worth the clearer syntax.
> >>
> >> Another possible syntax (dunno whether this has already been suggested
> >> on-list):
> >>
> >> $function = { $x => 2 * $x };
> >> $function = { ($x) => 2 * $x };
> >> $function = | $x => 2 * $x |;
> >> $function = | ($x) => 2 * $x |;
> >>
> >> Nikita and Levi prefer it with parenthesis, I prefer it without,
> because I
> >> think it's unnecessary clutter.
> >>
> >> A reason to use | ... | instead of { ... } would be to allow future
> object
> >> literals.
> >>
> > Applying that to Sara's example becomes:
> > 8. $someDict->map({$v => $v * 2})->filter({$v => $v % 3});
> > 9. $someDict->map(|$v => $v * 2|)->filter(|$v => $v % 3|);
> >
> > I also find that parenthesis makes it cluttered.
> > $someDict->map({($v) => $v * 2})->filter({($v) => $v % 3});
> >
> > Cheers //Björn
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> I find it quite odd that people are claiming paren’s around 0 arguments is
> ‘clutter’, but curly braces or pipes around the entire thing is somehow not
> clutter. While I understand there are small differences like implicit
> return and automatic capturing, having such wildly different syntax to a
> regular still doesn’t make much sense to me.


The difference is that `{ ... }` or `| ... |` is required to be
unambiguous, otherwise it conflicts with other parser rules.

Regards, Niklas

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Stephen Reay]

> On 10 Jun 2017, at 15:19, Björn Larsson  wrote:
> 
> Den 2017-06-09 kl. 22:00, skrev Niklas Keller:
>> 2017-06-09 15:44 GMT+02:00 Sara Golemon :
>> 
>>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson 
>>> wrote:
 If I take the liberty in using the example above on our option list:
 1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
 2. $someDict->map(function($v) => $v * 2)->filter(function($v) => $v %
>>> 3);
 3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
 4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);//
 Ambiguous
 5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);
 
 Old proposals:
 6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
 7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v % 3);
 
>>> Something else which really pops in these examples is the effect of
>>> not needing to use parentheses when embedding a single-arg short
>>> lambda.   3 and 6 in your list read cleaner to me (due to the lack of
>>> parenthesis clutter).  Sadly ~> has the same hacky implementation
>>> issues as ==>, but I think that shows a little bit of why the HackLang
>>> team decided the messy lexer was worth the clearer syntax.
>> 
>> Another possible syntax (dunno whether this has already been suggested
>> on-list):
>> 
>> $function = { $x => 2 * $x };
>> $function = { ($x) => 2 * $x };
>> $function = | $x => 2 * $x |;
>> $function = | ($x) => 2 * $x |;
>> 
>> Nikita and Levi prefer it with parenthesis, I prefer it without, because I
>> think it's unnecessary clutter.
>> 
>> A reason to use | ... | instead of { ... } would be to allow future object
>> literals.
>> 
> Applying that to Sara's example becomes:
> 8. $someDict->map({$v => $v * 2})->filter({$v => $v % 3});
> 9. $someDict->map(|$v => $v * 2|)->filter(|$v => $v % 3|);
> 
> I also find that parenthesis makes it cluttered.
> $someDict->map({($v) => $v * 2})->filter({($v) => $v % 3});
> 
> Cheers //Björn
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

I find it quite odd that people are claiming paren’s around 0 arguments is 
‘clutter’, but curly braces or pipes around the entire thing is somehow not 
clutter. While I understand there are small differences like implicit return 
and automatic capturing, having such wildly different syntax to a regular still 
doesn’t make much sense to me. 

Also, while object literals aren’t in php right now, I would imagine most 
developers would mentally parse that syntax as an object literal with a 
variable used for the key.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-09 kl. 22:00, skrev Niklas Keller:

2017-06-09 15:44 GMT+02:00 Sara Golemon :


On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson 
wrote:

If I take the liberty in using the example above on our option list:
1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
2. $someDict->map(function($v) => $v * 2)->filter(function($v) => $v %

3);

3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);//
Ambiguous
5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);

Old proposals:
6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v % 3);


Something else which really pops in these examples is the effect of
not needing to use parentheses when embedding a single-arg short
lambda.   3 and 6 in your list read cleaner to me (due to the lack of
parenthesis clutter).  Sadly ~> has the same hacky implementation
issues as ==>, but I think that shows a little bit of why the HackLang
team decided the messy lexer was worth the clearer syntax.


Another possible syntax (dunno whether this has already been suggested
on-list):

$function = { $x => 2 * $x };
$function = { ($x) => 2 * $x };
$function = | $x => 2 * $x |;
$function = | ($x) => 2 * $x |;

Nikita and Levi prefer it with parenthesis, I prefer it without, because I
think it's unnecessary clutter.

A reason to use | ... | instead of { ... } would be to allow future object
literals.


Applying that to Sara's example becomes:
8. $someDict->map({$v => $v * 2})->filter({$v => $v % 3});
9. $someDict->map(|$v => $v * 2|)->filter(|$v => $v % 3|);

I also find that parenthesis makes it cluttered.
$someDict->map({($v) => $v * 2})->filter({($v) => $v % 3});

Cheers //Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-09 kl. 15:44, skrev Sara Golemon:

On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson  wrote:

If I take the liberty in using the example above on our option list:
1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
2. $someDict->map(function($v) => $v * 2)->filter(function($v) => $v % 3);
3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);//
Ambiguous
5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);

Old proposals:
6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v % 3);


Something else which really pops in these examples is the effect of
not needing to use parentheses when embedding a single-arg short
lambda.   3 and 6 in your list read cleaner to me (due to the lack of
parenthesis clutter).  Sadly ~> has the same hacky implementation
issues as ==>, but I think that shows a little bit of why the HackLang
team decided the messy lexer was worth the clearer syntax.


Yup, totally agree on that one. It improves redability and when you have
more parameters I find the parenthesis less disturbing like.
- $someDict->map(($v, $y) ==> $v * 2 + $y)->filter(($v, $y) ==> $v % 3 - 
$y);


Btw, do you think there is a way around the hacky implementation, given
that PHP now has a new and shining engine?

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Levi Morrison]

On Fri, Jun 9, 2017 at 4:43 PM, Rowan Collins  wrote:
> On 9 June 2017 21:00:48 BST, Niklas Keller  wrote:
>>2017-06-09 15:44 GMT+02:00 Sara Golemon :
>>
>>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson
>>
>>> wrote:
>>> > If I take the liberty in using the example above on our option
>>list:
>>> > 1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
>>> > 2. $someDict->map(function($v) => $v * 2)->filter(function($v) =>
>>$v %
>>> 3);
>>> > 3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
>>> > 4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);
>>//
>>> > Ambiguous
>>> > 5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);
>>> >
>>> > Old proposals:
>>> > 6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
>>> > 7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v %
>>3);
>>> >
>>> Something else which really pops in these examples is the effect of
>>> not needing to use parentheses when embedding a single-arg short
>>> lambda.   3 and 6 in your list read cleaner to me (due to the lack of
>>> parenthesis clutter).  Sadly ~> has the same hacky implementation
>>> issues as ==>, but I think that shows a little bit of why the
>>HackLang
>>> team decided the messy lexer was worth the clearer syntax.
>>
>>
>>Another possible syntax (dunno whether this has already been suggested
>>on-list):
>>
>>$function = { $x => 2 * $x };
>>$function = { ($x) => 2 * $x };
>>$function = | $x => 2 * $x |;
>>$function = | ($x) => 2 * $x |;
>>
>>Nikita and Levi prefer it with parenthesis, I prefer it without,
>>because I
>>think it's unnecessary clutter.
>
> I already suggested the brace version, and Levi said it would conflict in the 
> parser: https://externals.io/thread/911#email-15331 I don't know enough about 
> parsing to comment on what workarounds would be possible.


It ends up not conflicting; when at top level you can keep existing
behavior and otherwise make it a closure. Given that creating a
closure without assigning it to variable or passing it to a function
is useless this is fine.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rowan Collins]

On 9 June 2017 21:00:48 BST, Niklas Keller  wrote:
>2017-06-09 15:44 GMT+02:00 Sara Golemon :
>
>> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson
>
>> wrote:
>> > If I take the liberty in using the example above on our option
>list:
>> > 1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
>> > 2. $someDict->map(function($v) => $v * 2)->filter(function($v) =>
>$v %
>> 3);
>> > 3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
>> > 4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);   
>//
>> > Ambiguous
>> > 5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);
>> >
>> > Old proposals:
>> > 6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
>> > 7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v %
>3);
>> >
>> Something else which really pops in these examples is the effect of
>> not needing to use parentheses when embedding a single-arg short
>> lambda.   3 and 6 in your list read cleaner to me (due to the lack of
>> parenthesis clutter).  Sadly ~> has the same hacky implementation
>> issues as ==>, but I think that shows a little bit of why the
>HackLang
>> team decided the messy lexer was worth the clearer syntax.
>
>
>Another possible syntax (dunno whether this has already been suggested
>on-list):
>
>$function = { $x => 2 * $x };
>$function = { ($x) => 2 * $x };
>$function = | $x => 2 * $x |;
>$function = | ($x) => 2 * $x |;
>
>Nikita and Levi prefer it with parenthesis, I prefer it without,
>because I
>think it's unnecessary clutter.

I already suggested the brace version, and Levi said it would conflict in the 
parser: https://externals.io/thread/911#email-15331 I don't know enough about 
parsing to comment on what workarounds would be possible.

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Niklas Keller]

2017-06-09 15:44 GMT+02:00 Sara Golemon :

> On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson 
> wrote:
> > If I take the liberty in using the example above on our option list:
> > 1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
> > 2. $someDict->map(function($v) => $v * 2)->filter(function($v) => $v %
> 3);
> > 3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
> > 4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);//
> > Ambiguous
> > 5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);
> >
> > Old proposals:
> > 6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
> > 7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v % 3);
> >
> Something else which really pops in these examples is the effect of
> not needing to use parentheses when embedding a single-arg short
> lambda.   3 and 6 in your list read cleaner to me (due to the lack of
> parenthesis clutter).  Sadly ~> has the same hacky implementation
> issues as ==>, but I think that shows a little bit of why the HackLang
> team decided the messy lexer was worth the clearer syntax.


Another possible syntax (dunno whether this has already been suggested
on-list):

$function = { $x => 2 * $x };
$function = { ($x) => 2 * $x };
$function = | $x => 2 * $x |;
$function = | ($x) => 2 * $x |;

Nikita and Levi prefer it with parenthesis, I prefer it without, because I
think it's unnecessary clutter.

A reason to use | ... | instead of { ... } would be to allow future object
literals.

Regards, Niklas

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Sara Golemon]

On Fri, Jun 9, 2017 at 7:23 AM, Björn Larsson  wrote:
> If I take the liberty in using the example above on our option list:
> 1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
> 2. $someDict->map(function($v) => $v * 2)->filter(function($v) => $v % 3);
> 3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
> 4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);//
> Ambiguous
> 5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);
>
> Old proposals:
> 6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
> 7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v % 3);
>
Something else which really pops in these examples is the effect of
not needing to use parentheses when embedding a single-arg short
lambda.   3 and 6 in your list read cleaner to me (due to the lack of
parenthesis clutter).  Sadly ~> has the same hacky implementation
issues as ==>, but I think that shows a little bit of why the HackLang
team decided the messy lexer was worth the clearer syntax.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-09 kl. 02:13, skrev Sara Golemon:


On Thu, Jun 8, 2017 at 4:56 PM, Björn Larsson  wrote:

You have a good point here! I think one then should evaluate
both the implementation, which apparently is not so great and
how the feature itself has been received.

I mean is it heavily used and what is the user feedback? E.g. are
users happy with the syntax and how do they use it.


As I already mentioned, the HHVM implementation is hackish, but the
reception around Facebook about the feature itself was SUPER positive.
Particularly when paired with collections.  $someDict->map($v ==> $v *
2)->filter($v ==> $v % 3); just reads way cleaner than the old
expressions.

FWIW, (with my HHVM hat on) we'd also discussed that we wouldn't be
too bothered if PHP went with a different syntax as it would ease
pressure to match behavior on a feature that's already widely deployed
internally.  So don't worry about picking a symbol based on what Hack
uses.  Pick what makes sense for PHP.  For my part, I care FAR more
that we get short closures than what gymnastics my fingers have to
partake.


Well, that is a good indication that this feature is really needed
and that the short syntax isn't seen as cumbersome in the HACK
comunity at least. If I be so bold then, to say that the main issue
with short syntax in PHP is the implementation, not the syntax.
But of course, not all like the short syntax...

If I take the liberty in using the example above on our option list:
1. $someDict->map(fn($v) => $v * 2)->filter(fn($v) => $v % 3);
2. $someDict->map(function($v) => $v * 2)->filter(function($v) => $v % 3);
3. $someDict->map($v ==> $v * 2)->filter($v ==> $v % 3);
4. $someDict->map(($v) => $v * 2)->filter(($v) => $v % 3);// 
Ambiguous

5. $someDict->map([]($v) => $v * 2)->filter([]($v) => $v % 3);

Old proposals:
6. $someDict->map($v ~> $v * 2)->filter($v ~> $v % 3);
7. $someDict->map(lambda($v) => $v * 2)->filter(lambda($v) => $v % 3);

Interesting example, it shows one benefit for arrow functions
compared to anonymous function is not saving keystrokes, but
improving readability when the arrow function is embedded
into something else.

Also having a short syntax improves the readability further
in my eyes. But using "lambda" has the benefit that we here
talk about something different compared to "function" and
what it is.

r//Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Sara Golemon]

On Thu, Jun 8, 2017 at 4:56 PM, Björn Larsson  wrote:
> You have a good point here! I think one then should evaluate
> both the implementation, which apparently is not so great and
> how the feature itself has been received.
>
> I mean is it heavily used and what is the user feedback? E.g. are
> users happy with the syntax and how do they use it.
>
As I already mentioned, the HHVM implementation is hackish, but the
reception around Facebook about the feature itself was SUPER positive.
Particularly when paired with collections.  $someDict->map($v ==> $v *
2)->filter($v ==> $v % 3); just reads way cleaner than the old
expressions.

FWIW, (with my HHVM hat on) we'd also discussed that we wouldn't be
too bothered if PHP went with a different syntax as it would ease
pressure to match behavior on a feature that's already widely deployed
internally.  So don't worry about picking a symbol based on what Hack
uses.  Pick what makes sense for PHP.  For my part, I care FAR more
that we get short closures than what gymnastics my fingers have to
partake.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-08 kl. 19:21, skrev Fleshgrinder:


On 6/8/2017 6:28 PM, Rasmus Schultz wrote:

it could be a single symbol instead of two

even if this can be done without parser ambiguity, it suffers from visual
ambiguity with the assignment operator.

consider what this would look like if the expression itself uses the
assignment operator...

 f($x) = $y = $y + $x;

versus something like:

 f($x) => $y = $y + $x;

even that is visually ambiguous when used in arrays though:

 $a = [
 "foo" => f($x) => $y = $y + $x,
 ];

also unreadable.

even if the parser can cope, I think we need some other symbol that isn't
visually ambiguous when used in these contexts?


Absolutely, yes.

One thing that could work is a combination of colon and equal sign with
an optional type in between:

 f($x, &$y):= $y = $y + $x
 f($x, &$y): int = $y = $y + $x

Still, kind of ambiguous if used with a type. Earlier I used the greater
than sign only:

 f($x, $y)> $x > $y
 f($x, $y): bool > $x > $y

As we can clearly see, also not optimal. A thing that should work is a
hyphen greater than:

 f(object $o)->$o->property

Looks weird without proper spacing, but with proper spacing ...

 f(object $o) -> $o->property

... it looks fine, imho. Of course, we still have the other options that
were mentioned earlier already:

 f ~> 42  // bad on some keyboard layouts
 f ==> 42 // I personally do not like this option

Another possibility is to use a keyword. This would definitely avoid
symbol soup and help visual recognition:

 f do 42
 f($x) do $x^3
 f($x, &$y) do $y = $y + $x

However, I am very unsure about this option to be honest.

I'd say my choice here is `~>` but I'm on a US layout, second is `->`.
Note that the latter is used in Java, Elixier, Erlang, Haskell, Julia,
OCaml, F#, and probably others.


Well, one reason ~> came up in the earlier RFC was that ==> was not seen as
quite the best. I liked the tilde option then and do it now. For me that 
sits on
a nordic keyboard layout, I need to use Alt-gr both for $ and ~, extra 
space for

tilde though. So using tilde is no big hassle ;-)

So not all liked the syntax then, but there was other things making that RFC
fail. If type hinting had been included and variable binding had been 
slightly

different, I think it might have passed.

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-08 kl. 15:34, skrev Rowan Collins:


On 08/06/2017 13:33, Björn Larsson wrote:

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.



You have a good point here! I think one then should evaluate
both the implementation, which apparently is not so great and
how the feature itself has been received.

I mean is it heavily used and what is the user feedback? E.g. are
users happy with the syntax and how do they use it.

r//Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Fleshgrinder]

On 6/8/2017 6:28 PM, Rasmus Schultz wrote:
>> it could be a single symbol instead of two
> 
> even if this can be done without parser ambiguity, it suffers from visual
> ambiguity with the assignment operator.
> 
> consider what this would look like if the expression itself uses the
> assignment operator...
> 
> f($x) = $y = $y + $x;
> 
> versus something like:
> 
> f($x) => $y = $y + $x;
> 
> even that is visually ambiguous when used in arrays though:
> 
> $a = [
> "foo" => f($x) => $y = $y + $x,
> ];
> 
> also unreadable.
> 
> even if the parser can cope, I think we need some other symbol that isn't
> visually ambiguous when used in these contexts?
> 

Absolutely, yes.

One thing that could work is a combination of colon and equal sign with
an optional type in between:

f($x, &$y):= $y = $y + $x
f($x, &$y): int = $y = $y + $x

Still, kind of ambiguous if used with a type. Earlier I used the greater
than sign only:

f($x, $y)> $x > $y
f($x, $y): bool > $x > $y

As we can clearly see, also not optimal. A thing that should work is a
hyphen greater than:

f(object $o)->$o->property

Looks weird without proper spacing, but with proper spacing ...

f(object $o) -> $o->property

... it looks fine, imho. Of course, we still have the other options that
were mentioned earlier already:

f ~> 42  // bad on some keyboard layouts
f ==> 42 // I personally do not like this option

Another possibility is to use a keyword. This would definitely avoid
symbol soup and help visual recognition:

f do 42
f($x) do $x^3
f($x, &$y) do $y = $y + $x

However, I am very unsure about this option to be honest.

I'd say my choice here is `~>` but I'm on a US layout, second is `->`.
Note that the latter is used in Java, Elixier, Erlang, Haskell, Julia,
OCaml, F#, and probably others.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

> it could be a single symbol instead of two

even if this can be done without parser ambiguity, it suffers from visual
ambiguity with the assignment operator.

consider what this would look like if the expression itself uses the
assignment operator...

f($x) = $y = $y + $x;

versus something like:

f($x) => $y = $y + $x;

even that is visually ambiguous when used in arrays though:

$a = [
"foo" => f($x) => $y = $y + $x,
];

also unreadable.

even if the parser can cope, I think we need some other symbol that isn't
visually ambiguous when used in these contexts?


On Thu, Jun 8, 2017 at 5:56 PM, Fleshgrinder  wrote:

> On 6/7/2017 9:45 PM, Rasmus Schultz wrote:
> >> 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
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Sara Golemon]

On Thu, Jun 8, 2017 at 9:34 AM, Rowan Collins  wrote:
> On 08/06/2017 13:33, Björn Larsson wrote:
>>
>> 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.
>
This is true.  The bodge to make (args...) ==> expr work in HackLang
isn't worthy of replicating in PHP.  If we can do it without a hack*
then by all means, let's not diverge the implementations.  But I
didn't want to maintain that lexer "is it a T_OP or a '('?" mess in
HHVM, I don't wanna maintain it in PHP either.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Fleshgrinder]

On 6/7/2017 9:45 PM, Rasmus Schultz wrote:
>> 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



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rowan Collins]

On 08/06/2017 13:33, Björn Larsson wrote:

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]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-07 kl. 17:20, skrev Stephen Reay:

On 7 Jun 2017, at 20:37, Björn Larsson  wrote:

Well, one reason to use fn or even lambda was to signal that this is
different then a regular function.

When it comes to number of keystrokes I guess that some inspiration
has been taken from other languages supporting arrow functions, like
Javascript & HACK.

I also recall from earlier discussions, that with less keystrokes it's easier
to read when an arrow function is embedded / chained into another
expression / statement / function call.


I think its pretty clear my pref is/was #2, but when compared to the crazy 
alternatives people have been suggesting, which just seem to be “hold down shift 
and blindly poke at the non-letter keys for a while”, the `fn($a, $b) => $a + 
$b ** $c` syntax suddenly becomes an acceptable compromise.


Yup, I also think that one is better then function. One reason
(not the only one) for me to advocate ==> syntax is that it's the
same syntax as HACK. However, apparently this one requires
more of the parser and it's tricky if typehints comes into the
equation.

Still my favourite one is option 3 if it would be possible to
implement.

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

> 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 :-)


On Wed, Jun 7, 2017 at 5:20 PM, Stephen Reay 
wrote:

>
> > On 7 Jun 2017, at 20:37, Björn Larsson 
> wrote:
> >
> > Well, one reason to use fn or even lambda was to signal that this is
> > different then a regular function.
> >
> > When it comes to number of keystrokes I guess that some inspiration
> > has been taken from other languages supporting arrow functions, like
> > Javascript & HACK.
> >
> > I also recall from earlier discussions, that with less keystrokes it's
> easier
> > to read when an arrow function is embedded / chained into another
> > expression / statement / function call.
> >
>
>
> I think its pretty clear my pref is/was #2, but when compared to the crazy
> alternatives people have been suggesting, which just seem to be “hold down
> shift and blindly poke at the non-letter keys for a while”, the `fn($a, $b)
> => $a + $b ** $c` syntax suddenly becomes an acceptable compromise.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Stephen Reay]

> On 7 Jun 2017, at 20:37, Björn Larsson  wrote:
> 
> Well, one reason to use fn or even lambda was to signal that this is
> different then a regular function.
> 
> When it comes to number of keystrokes I guess that some inspiration
> has been taken from other languages supporting arrow functions, like
> Javascript & HACK.
> 
> I also recall from earlier discussions, that with less keystrokes it's easier
> to read when an arrow function is embedded / chained into another
> expression / statement / function call.
> 


I think its pretty clear my pref is/was #2, but when compared to the crazy 
alternatives people have been suggesting, which just seem to be “hold down 
shift and blindly poke at the non-letter keys for a while”, the `fn($a, $b) => 
$a + $b ** $c` syntax suddenly becomes an acceptable compromise.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-06 kl. 06:38, skrev Stephen Reay:


On 6 Jun 2017, at 03:18, Björn Larsson  wrote:

Den 2017-06-05 kl. 21:23, skrev Ryan Pallas:


On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder  wrote:


On 6/5/2017 9:03 PM, Ryan Pallas wrote:

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



I can get behind using the tilde. Keeps it concise, but it's visually
different than existing syntax, making it easier to recognize (IMO).


I think ~>was a proposal in the short closure RFC. Personally I liked it,
but could also live with ==>. I recall there was a discussion about how
easy it was to use tilde on different keyboards / languages. So at that
point the discussion was about either ~> or ==> for syntax.

But back to Levi's list it looks like, at least to me that option 2 & 4 are
off the table. Leaving option 3 & 1, maybe also option 5.

Do you think this is a reasonable assumption?

Also some other proposals has arisen, like using lamda instead of fn as
a keyword and lastly the ~> one.

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

As someone who sees limited appeal in short closures (Ok, they may make for 
slightly simpler constructs that are slightly too complex for a regular 
“collect” type collection method), I see a *lot* of people spending a *lot* of 
time to save typing 8 characters (function).

If this feature truly is about making it easier to read, then that should be your goal: 
make it easy to mentally parse, basically instantly. Given that even proponents of the 
approach are admitting the syntax can get quite hard to understand quickly, perhaps 
it’s time to accept that “more characters” !== “harder to read & understand” and 
importantly, “less characters” !== “easier to read & understand”.

How long does it take someone to type function? A second, maybe two? How many 
times are other people going to read that, once it’s been written?


Or maybe I’ve got it all wrong, and the goal is literally to save 8 keystrokes. 
If that’s the case, please update the RFC accordingly, to make it clear what 
the motivations are


Well, one reason to use fn or even lambda was to signal that this is
different then a regular function.

When it comes to number of keystrokes I guess that some inspiration
has been taken from other languages supporting arrow functions, like
Javascript & HACK.

I also recall from earlier discussions, that with less keystrokes it's 
easier

to read when an arrow function is embedded / chained into another
expression / statement / function call.

r//Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Fleshgrinder]

On 6/6/2017 6:38 AM, Stephen Reay wrote:
> As someone who sees limited appeal in short closures (Ok, they may
> make for slightly simpler constructs that are slightly too complex
> for a regular “collect” type collection method), I see a *lot* of
> people spending a *lot* of time to save typing 8 characters
> (function).
> 
> If this feature truly is about making it easier to read, then that
> should be your goal: make it easy to mentally parse, basically
> instantly. Given that even proponents of the approach are admitting
> the syntax can get quite hard to understand quickly, perhaps it’s
> time to accept that “more characters” !== “harder to read &
> understand” and importantly, “less characters” !== “easier to read &
> understand”.
> 
> How long does it take someone to type function? A second, maybe two?
> How many times are other people going to read that, once it’s been
> written?
> 

I can only agree once more. PHP is verbose, PHP always was verbose, PHP
should stay verbose. Not to say that short closures are bad, but
searching for the perfect symbol soup seems wrong. We could easily
create a syntax that is totally unambiguous and easy on the parser
without lots of look-ahead with a new keyword.

fn> 42
fn($a, $b)> $a + $b
fn($a) (&$b)> $b += $a

$a = [fn()> 42];

usort($data, fn(T $a, T $b):int> $a <=> $b);

Our (simplified) production rule would be (where brackets denote optional):

"fn" [ (" [P] ")" ] [ "(" U ")" ] [ ":" T ] ">" E

P  := param list
U  := use list
T  := return type
E  := expression (to return the result of)

This would also ensure that nobody can use it for more complicated
expression, since we are not supporting braces. Anything complex should
continue to use the long closure notation, as it is more readable.

Extending this for usage with methods would also be quite easy. In that
case we can even drop the keyword (methods require a name anyways):

final class SomeEnum {
  // ...
  public static Foo(): self > new static('foo');
  public static Bar(): self > new static('bar');
}

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Stephen Reay]

> 
> On 6 Jun 2017, at 03:18, Björn Larsson  wrote:
> 
> Den 2017-06-05 kl. 21:23, skrev Ryan Pallas:
> 
>> On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder  wrote:
>> 
>>> On 6/5/2017 9:03 PM, Ryan Pallas wrote:
 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
>>> 
>>> 
>> I can get behind using the tilde. Keeps it concise, but it's visually
>> different than existing syntax, making it easier to recognize (IMO).
>> 
> I think ~>was a proposal in the short closure RFC. Personally I liked it,
> but could also live with ==>. I recall there was a discussion about how
> easy it was to use tilde on different keyboards / languages. So at that
> point the discussion was about either ~> or ==> for syntax.
> 
> But back to Levi's list it looks like, at least to me that option 2 & 4 are
> off the table. Leaving option 3 & 1, maybe also option 5.
> 
> Do you think this is a reasonable assumption?
> 
> Also some other proposals has arisen, like using lamda instead of fn as
> a keyword and lastly the ~> one.
> 
> r//Björn
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

As someone who sees limited appeal in short closures (Ok, they may make for 
slightly simpler constructs that are slightly too complex for a regular 
“collect” type collection method), I see a *lot* of people spending a *lot* of 
time to save typing 8 characters (function).

If this feature truly is about making it easier to read, then that should be 
your goal: make it easy to mentally parse, basically instantly. Given that even 
proponents of the approach are admitting the syntax can get quite hard to 
understand quickly, perhaps it’s time to accept that “more characters” !== 
“harder to read & understand” and importantly, “less characters” !== “easier to 
read & understand”.

How long does it take someone to type function? A second, maybe two? How many 
times are other people going to read that, once it’s been written?


Or maybe I’ve got it all wrong, and the goal is literally to save 8 keystrokes. 
If that’s the case, please update the RFC accordingly, to make it clear what 
the motivations are 



Cheers

Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-05 kl. 21:23, skrev Ryan Pallas:


On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder  wrote:


On 6/5/2017 9:03 PM, Ryan Pallas wrote:

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



I can get behind using the tilde. Keeps it concise, but it's visually
different than existing syntax, making it easier to recognize (IMO).


I think ~>was a proposal in the short closure RFC. Personally I liked it,
but could also live with ==>. I recall there was a discussion about how
easy it was to use tilde on different keyboards / languages. So at that
point the discussion was about either ~> or ==> for syntax.

But back to Levi's list it looks like, at least to me that option 2 & 4 are
off the table. Leaving option 3 & 1, maybe also option 5.

Do you think this is a reasonable assumption?

Also some other proposals has arisen, like using lamda instead of fn as
a keyword and lastly the ~> one.

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rowan Collins]

On 05/06/2017 20:09, Fleshgrinder wrote:

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).


We've come full circle: that was actually the syntax proposed in Bob 
Weinand's (rejected) RFC two years ago: 
https://wiki.php.net/rfc/short_closures


There are several reasons the RFC was rejected, but IIRC the syntax was 
one of them. I think ~ isn't available on all keyboard layouts, and some 
people just didn't like the look of it.



Looking at earlier drafts of the current RFC reminds me of a couple of 
points which have been slimmed down a bit in the current edit:


1) As well as inside arrays, => is used to represent key-value pairs in 
yield statements:


// Does this mean:
//   1. Yield a key with the result of `($x)` and a value with `$x * 2`
//   2. Yield an anonymous function
yield ($x) => $x * 2;

2) The prefix (fn, function, lambda, etc) allows us to insert type hints 
without adding awkward complexities to the parser:


> In the definition (Type &$x) => expr the part (Type &$var) can parse 
as “take constant Type and variable $var and do a bitwise and & operation.”
> After that the => will be an unexpected token. Even though the rule 
would be invalid the parser doesn't know that far ahead there will be an 
error and it doesn't know which rule to pick.


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Ryan Pallas]

On Mon, Jun 5, 2017 at 1:09 PM, Fleshgrinder  wrote:

> On 6/5/2017 9:03 PM, Ryan Pallas wrote:
> > 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
>
>
I can get behind using the tilde. Keeps it concise, but it's visually
different than existing syntax, making it easier to recognize (IMO).


> --
> Richard "Fleshgrinder" Fussenegger
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Fleshgrinder]

On 6/5/2017 9:03 PM, Ryan Pallas wrote:
> 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



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Ryan Pallas]

On Jun 5, 2017 12:53 PM, "Fleshgrinder"  wrote:

On 6/5/2017 8:36 PM, Rasmus Schultz wrote:
> Ugh, you're right, that's totally unreadable... the => is far too
ambiguous
> with array syntax, I agree.
>
> How about just a thin arrow?
>
> (params) -> expr
>
> If the parens around params were required, it's not ambiguous with the
> trailing -- operator, is it?
>
> $foo->bar(($baz) -> $baz + 1);
>
> Consistent use of parens around the params might make closures a bit
easier
> to spot in the wild?
>

This would actually work with everything, me likes.

  () -> 42
  ($a, $b) -> $a + $b
  ($a) (&$b) -> $b += $a

  public static Foo() -> new static('Foo');


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


It also avoid any association with 

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Fleshgrinder]

On 6/5/2017 8:36 PM, Rasmus Schultz wrote:
> Ugh, you're right, that's totally unreadable... the => is far too ambiguous
> with array syntax, I agree.
> 
> How about just a thin arrow?
> 
> (params) -> expr
> 
> If the parens around params were required, it's not ambiguous with the
> trailing -- operator, is it?
> 
> $foo->bar(($baz) -> $baz + 1);
> 
> Consistent use of parens around the params might make closures a bit easier
> to spot in the wild?
> 

This would actually work with everything, me likes.

  () -> 42
  ($a, $b) -> $a + $b
  ($a) (&$b) -> $b += $a

  public static Foo() -> new static('Foo');

It also avoid any association with 

signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

Ugh, you're right, that's totally unreadable... the => is far too ambiguous
with array syntax, I agree.

How about just a thin arrow?

(params) -> expr

If the parens around params were required, it's not ambiguous with the
trailing -- operator, is it?

$foo->bar(($baz) -> $baz + 1);

Consistent use of parens around the params might make closures a bit easier
to spot in the wild?


On Mon, Jun 5, 2017 at 8:11 PM, Björn Larsson 
wrote:

>
>
> Den 2017-06-05 kl. 19:55, skrev Rowan Collins:
>
>> On 5 June 2017 18:17:06 BST, Fleshgrinder  wrote:
>>
>>> Could someone explain me again what the problem with the simple
>>> fat-arrow and normal parenthesis is? Cannot find it anymore (too many
>>> messages in too many thread I guess). I would guess that it has to do
>>> with the arbitrary look-ahead that is required to check for the fat
>>> arrow before the lexer knows that this is a short closure and not some
>>> parenthesis that simply groups something.
>>>
>> I think it's not just a case of implementation problems, it's actually
>> ambiguous with current syntax:
>>
>> $foo = array( ($x) => 42 );
>>
>> Sure, those inner brackets are redundant, so it's not likely to break
>> much actual code, but it's kind of weird to have this one case magically
>> turn into a closure, when anything else you put in those brackets would
>> just be used as the array key:
>>
>> $foo = array( f($x) => 42 );
>> $foo = array( ($x+1) => 42 );
>> $foo = array( (42) => $x );
>> $foo = array( (X) => 42 );
>> $foo = array( ($x) => 42 );
>> $foo = array( ("$x") => 42 );
>>
>> Even if we could teach the parser to understand it, I'd personally be
>> against it for the difficulty of *humans* parsing it. I find shorthand
>> closures hard enough to read anyway, especially when people suggest things
>> like ($x) => ($y) => $x * $y * $z;
>>
>> Regards,
>>
>> +1, think you nailed it here :) One of the reasons I prefer the ==>
> syntax.
>
> r//Björn
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-06-05 kl. 19:55, skrev Rowan Collins:

On 5 June 2017 18:17:06 BST, Fleshgrinder  wrote:

Could someone explain me again what the problem with the simple
fat-arrow and normal parenthesis is? Cannot find it anymore (too many
messages in too many thread I guess). I would guess that it has to do
with the arbitrary look-ahead that is required to check for the fat
arrow before the lexer knows that this is a short closure and not some
parenthesis that simply groups something.

I think it's not just a case of implementation problems, it's actually 
ambiguous with current syntax:

$foo = array( ($x) => 42 );

Sure, those inner brackets are redundant, so it's not likely to break much 
actual code, but it's kind of weird to have this one case magically turn into a 
closure, when anything else you put in those brackets would just be used as the 
array key:

$foo = array( f($x) => 42 );
$foo = array( ($x+1) => 42 );
$foo = array( (42) => $x );
$foo = array( (X) => 42 );
$foo = array( ($x) => 42 );
$foo = array( ("$x") => 42 );

Even if we could teach the parser to understand it, I'd personally be against it for 
the difficulty of *humans* parsing it. I find shorthand closures hard enough to read 
anyway, especially when people suggest things like ($x) => ($y) => $x * $y * $z;

Regards,


+1, think you nailed it here :) One of the reasons I prefer the ==> syntax.

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Fleshgrinder]

On 6/5/2017 7:55 PM, Rowan Collins wrote:
> I think it's not just a case of implementation problems, it's actually 
> ambiguous with current syntax:
> 
> $foo = array( ($x) => 42 );
> 
> Sure, those inner brackets are redundant, so it's not likely to break much 
> actual code, but it's kind of weird to have this one case magically turn into 
> a closure, when anything else you put in those brackets would just be used as 
> the array key:
> 
> $foo = array( f($x) => 42 );
> $foo = array( ($x+1) => 42 );
> $foo = array( (42) => $x );
> $foo = array( (X) => 42 );
> $foo = array( ($x) => 42 );
> $foo = array( ("$x") => 42 );
> 
> Even if we could teach the parser to understand it, I'd personally be against 
> it for the difficulty of *humans* parsing it. I find shorthand closures hard 
> enough to read anyway, especially when people suggest things like ($x) => 
> ($y) => $x * $y * $z;
> 
> Regards,
> 

Ah thanks, yeah, that was the problem.

At trivago we have such a super fancy ES6 code base where everything is
done in a super cryptic syntax, so that absolutely nobody who is not
used to reading this all day has a chance to understand a single thing.
So, yeah, I completely agree with you on everything.

That being said, they are handy if not overused, like so many features. :)

The pipes should still be in the game.

$foo = array( |$x| => 42 );

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rowan Collins]

On 5 June 2017 18:17:06 BST, Fleshgrinder  wrote:
>Could someone explain me again what the problem with the simple
>fat-arrow and normal parenthesis is? Cannot find it anymore (too many
>messages in too many thread I guess). I would guess that it has to do
>with the arbitrary look-ahead that is required to check for the fat
>arrow before the lexer knows that this is a short closure and not some
>parenthesis that simply groups something. 

I think it's not just a case of implementation problems, it's actually 
ambiguous with current syntax:

$foo = array( ($x) => 42 );

Sure, those inner brackets are redundant, so it's not likely to break much 
actual code, but it's kind of weird to have this one case magically turn into a 
closure, when anything else you put in those brackets would just be used as the 
array key:

$foo = array( f($x) => 42 );
$foo = array( ($x+1) => 42 );
$foo = array( (42) => $x );
$foo = array( (X) => 42 );
$foo = array( ($x) => 42 );
$foo = array( ("$x") => 42 );

Even if we could teach the parser to understand it, I'd personally be against 
it for the difficulty of *humans* parsing it. I find shorthand closures hard 
enough to read anyway, especially when people suggest things like ($x) => ($y) 
=> $x * $y * $z;

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Fleshgrinder]

On 6/5/2017 6:17 PM, Larry Garfield wrote:
> 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
> 

I agree with Larry here. Another thing that would be great to have is a
universal syntax that we can expand to cover methods at a later point
too. Ceylon has that available everywhere, and it is nice for writing
simple methods.

final class SomeEnum {
private $v;

private __construct(string $v) => $this->v = $v;

public static Foo() => new static('FOO');
public static Bar() => new static('BAR');
}

Could someone explain me again what the problem with the simple
fat-arrow and normal parenthesis is? Cannot find it anymore (too many
messages in too many thread I guess). I would guess that it has to do
with the arbitrary look-ahead that is required to check for the fat
arrow before the lexer knows that this is a short closure and not some
parenthesis that simply groups something. Wouldn't it be possible to go
for the pipes then? I mean, pipes without an expression to the left are
not valid right now, and they most probably will never be. Union types
might require them, but they are not lonely there too. Hence:

|| 42
function () { return 42; }

|$a, $b| $a + $b
function () { return $a + $b; }

References and use should be easy to add:

|$a| |&$b| $b += $a
function ($a) use (&$b) { return ($b += $a); }

This syntax does not translate nicely to method though:

public static Foo|| new static('FOO');

Looks kind 'a weird and now we have something on the lhs of the pipes
that looks very much like a union type. We could still go for the fat
arrow syntax here, even if the pipes are used for short closures. The
two features are not the same after all.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Larry Garfield]

On 06/05/2017 09:19 AM, Rasmus Schultz wrote:

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 
wrote:


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

On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:

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
5.
[](params) => expr // binds no values
[=](params) => expr // binds by value
[&](params) => 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

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 
wrote:

> Den 2017-06-01 kl. 18:58, skrev Theodore Brown:
>
> On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:
>>
>> 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
>>> 5.
>>> [](params) => expr // binds no values
>>> [=](params) => expr // binds by value
>>> [&](params) => 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.
>>
>
> As a user land developer, option 3 is also my favourite followed by 5 and
> last 1.
>
> However, for option 5 I would prefer ==> syntax and for option 1 I would
> prefer
> lambda as a keyword instead of fn.
>
> One thought that struck me, would option 3 be possible to extend also
> including
> option 5 either as a voting option or in a future RFC?
>
> And yes, arrow functions is much welcome!
>
> r//Björn
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

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


On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:


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
5.
[](params) => expr // binds no values
[=](params) => expr // binds by value
[&](params) => 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.


As a user land developer, option 3 is also my favourite followed by 5 
and last 1.


However, for option 5 I would prefer ==> syntax and for option 1 I would 
prefer

lambda as a keyword instead of fn.

One thought that struck me, would option 3 be possible to extend also 
including

option 5 either as a voting option or in a future RFC?

And yes, arrow functions is much welcome!

r//Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Theodore Brown]

On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:

> 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
> 5.
> [](params) => expr // binds no values
> [=](params) => expr // binds by value
> [&](params) => 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[ilija . tovilo]

I think it’s worth noting that the people most excited about arrow functions 
are probably the ones with a more functional approach.
Those kinds of side effects are usually avoided.

I also have nothing against capturing by reference. Given the last example:

fn($item) => $array[] = $item

All you have to do is glance a few characters to the left to see that $array is 
not a parameter and thus must be captured. And again, since it’s pretty obvious 
to see if you’re mutating the variable (spot the equal sign) this shouldn’t 
cause too many surprises. Only scenario I can think of is passing it to another 
function as a reference. But then again, no one ever complains about that in 
other languages.

Ilija


On 31 May 2017, 23:11 +0200, Levi Morrison , wrote:
> > I can’t think of a scenario where capturing by reference would be helpful in
> > a single line closure.
>
> function($item) use($array) {
> return $array[] = $item;
> }
>
> It's actually one of the first closures I discovered in the wild when
> looking for closures that would be candidates for the short form.

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Levi Morrison]

> I can’t think of a scenario where capturing by reference would be helpful in
> a single line closure.

function($item) use($array) {
return $array[] = $item;
}

It's actually one of the first closures I discovered in the wild when
looking for closures that would be candidates for the short form.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[ilija . tovilo]

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


On 30 May 2017, 19:58 +0200, 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?
>
>
> [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.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rowan Collins]

On 31 May 2017 14:48:03 BST, Levi Morrison  wrote:
>On Wed, May 31, 2017 at 7:36 AM, Rowan Collins
> wrote:
>> 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 }
>
>This does not work. We permit expressions as statements and we also
>allow empty blocks:
>
>{
>$a = $foo;
>}
>
>These will conflict in the grammar.

Yeah, I wondered if that would be the case, but don't know enough about how 
parsers work to be sure one way or the other. It's not ambiguous, because the 
=> wouldn't be legal there, but I guess it's "too late" by the time that token 
is reached. :(

Regards,

-- 
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Levi Morrison]

On Wed, May 31, 2017 at 7:36 AM, Rowan Collins  wrote:
> On 30 May 2017 18:58:14 BST, 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.
>
> 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.

This does not work. We permit expressions as statements and we also
allow empty blocks:

{
$a = $foo;
}

These will conflict in the grammar.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rowan Collins]

On 30 May 2017 18:58:14 BST, 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.

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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

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


On Tue, May 30, 2017 at 3:37 PM, Björn Larsson
 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?


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)=> $x]  a bit similar to [($x)=> $x]
vs
2. [[]($x)==> $x] less similar to [($x)=> $x]

2 has in my eyes less soup factor...

Cheers //Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Levi Morrison]

On Tue, May 30, 2017 at 3:37 PM, Björn Larsson
 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?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

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?


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.

Well, maybe the option lambda(params) might be an alternative ;)

When it comes to the need of this feature one could weigh in that
languages like Javascript, Java, C# and HACK already have it.

Hm... maybe worth checking how much this feature is used in e.g.
HACK to see how large the need is.

Cheers //Björn

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[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".

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

Den 2017-05-30 kl. 20:24, skrev Levi Morrison:

On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
 wrote:

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.
   [](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?


[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

The compatibility issue is with `[](params)` is that it is currently
an empty array literal that will be invoked; this is guaranteed to be
an error at runtime so it is unlikely to cause much trouble. A
trailing `==>` would not help here.

Ok, but how about having ==> to improve readability and make it
less ambiguous & quicker to read the code. Also enable the syntax:
- (params) ==> expr// binds no values.

r//Björn


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Levi Morrison]

>> You mentioned ability to explicitly specify binding as a possible extension.
>> However
>>
>> [$var1, $var2]()
>>
>> is not necessarily failing right now, it may be a valid array callable.
>>
>> Nikita
>
> As already mentioned we must maintain a leading `=` or `&`:
>
>   [=, $var1, $var2]()
>   [=, $var1, $var2]()
>
> Sorry if that was unclear.

Oops, forgot to change the bottom line:

   [=, $var1, $var2]()
   [&, $var1, $var2]()

The first line means "bind any implicit usages of variables by value,
and also bind $var1 and $var2 by value".
The second line means "bind any implicit usages of variables by
reference, and bind $var1 and $var2 by value".

This exists in C++ but C++ allows you to drop the leading `=` or `&`.
We cannot, for precisely the reason you mentioned.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Levi Morrison]

On Tue, May 30, 2017 at 12:36 PM, Nikita Popov  wrote:
> On Tue, May 30, 2017 at 8:24 PM, Levi Morrison  wrote:
>>
>> On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
>>  wrote:
>> > 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.
>> >>   [](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?
>> >>
>> >>
>> >>[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
>>
>> The compatibility issue is with `[](params)` is that it is currently
>> an empty array literal that will be invoked; this is guaranteed to be
>> an error at runtime so it is unlikely to cause much trouble. A
>> trailing `==>` would not help here.
>
>
> You mentioned ability to explicitly specify binding as a possible extension.
> However
>
> [$var1, $var2]()
>
> is not necessarily failing right now, it may be a valid array callable.
>
> Nikita

As already mentioned we must maintain a leading `=` or `&`:

  [=, $var1, $var2]()
  [=, $var1, $var2]()

Sorry if that was unclear.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Nikita Popov]

On Tue, May 30, 2017 at 8:24 PM, Levi Morrison  wrote:

> On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
>  wrote:
> > 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.
> >>   [](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?
> >>
> >>
> >>[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
>
> The compatibility issue is with `[](params)` is that it is currently
> an empty array literal that will be invoked; this is guaranteed to be
> an error at runtime so it is unlikely to cause much trouble. A
> trailing `==>` would not help here.
>

You mentioned ability to explicitly specify binding as a possible
extension. However

[$var1, $var2]()

is not necessarily failing right now, it may be a valid array callable.

Nikita

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Levi Morrison]

On Tue, May 30, 2017 at 12:16 PM, Björn Larsson
 wrote:
> 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.
>>   [](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?
>>
>>
>>[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

The compatibility issue is with `[](params)` is that it is currently
an empty array literal that will be invoked; this is guaranteed to be
an error at runtime so it is unlikely to cause much trouble. A
trailing `==>` would not help here.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Björn Larsson]

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.
  [](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?


   [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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php