Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88536
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.44 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAB6YZuxQDPS8V67vof7wmg7oh1dv5dseNX5Uq5J=iUBYGWt7=Q@mail.gmail.com>
References: <CAFMT4NrOsRm_6Qb11cbtsq0H-_OYugu-u-3Q+EC9J3Ze9BNAYg@mail.gmail.com>
	<CAB6YZuxQDPS8V67vof7wmg7oh1dv5dseNX5Uq5J=iUBYGWt7=Q@mail.gmail.com>
Date: Mon, 28 Sep 2015 16:52:39 -0600
Message-ID: <CAFMT4NrsKR3etBoUAz2aAK1HmJToqgK5=rRMRaA3xH8RHtwYAA@mail.gmail.com>
To: =?UTF-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Arrow function expressions in PHP
From: levim@php.net (Levi Morrison)

On Mon, Sep 28, 2015 at 3:38 PM, Pavel Kou=C5=99il <pajousek@gmail.com> wro=
te:
> On Sat, Sep 26, 2015 at 6:17 PM, Levi Morrison <levim@php.net> wrote:
>> (Email in gist format:
>> https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c)
>>
>> In EcmaScript 2015 (ES6) the expression `(x) =3D> x * 2` means to create
>> an anonymous function with one parameter `x` that will return `x * 2`.
>> For example:
>>
>>     (x) =3D> x * 2
>>     // is equivalent to:
>>     function(x) { return x * 2; }
>>
>> A modified example from [documentation by Mozilla Developer
>> Network][1] page demonstrates how they are useful:
>>
>>     var a =3D [
>>         "Hydrogen",
>>         "Helium",
>>         "Lithium",
>>         "Beryl=C2=ADlium"
>>     ];
>>
>>     var a2 =3D a.map(function(s){ return s.length }); // pre-ES6
>>
>>     var a3 =3D a.map((s) =3D> s.length); // ES6
>>
>> There has been some talk about how we can use arrow function
>> expressions in PHP. In PHP using the same syntax would have some
>> ambiguities:
>>
>>     // Does this mean:
>>     //   1. Create an array key with the result of `($x)` and a value
>> with `$x * 2`
>>     //   2. Create an array with one value that is an anonymous function
>>     [($x) =3D> $x * 2]
>>
>>     // 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) =3D> $x * 2;
>>
>> This is why Bob Weinand [proposed][2] using `~>` instead of `=3D>`.
>> However, if we allow type declarations there is another issue. In the
>> definition `(Type &$x) =3D> expr` the `(Type &$var)` part can parse as
>> "take constant `Type` and variable `$var` and do a bitwise and `&`
>> operation." After that the `=3D>` will be an unexpected token. Even
>> though the rule would be invalid the parser doesn't know that far
>> ahead it will error and it doesn't know which rule to pick. Changing
>> the token from `=3D>` to `~>` doesn't affect this issue.
>>
>> We could solve the first ambiguities with prefering the current
>> meaning with `key =3D> value` and requiring the meaning with closures to
>> wrap them in `()`. We could solve the latter ambiguity with a
>> backtracking parser since it will eventually error and then know to
>> pick the other rule. However, I really think this is a bad idea.
>>
>> So how can we have shorter closures without this mess? One simple way
>> is to require the `function` prefix:
>>
>>     // clearly an array with an anonymous function
>>     [function($x) =3D> $x * 2];
>>
>>     // clearly yields an anonymous function
>>     yield function($x) =3D> $x * 2;
>>
>>     // clearly an anonymous function
>>     function(Type &$x) =3D> expr;
>>
>> Requiring the `function` prefix mitigates one of the value parts of
>> arrow functions: they are short.
>>
>> Another option would be to resolve the ambiguities with keys and
>> values but to change the type information in parameters:
>>
>>     (&$input: array) =3D> expr
>>
>> By putting the type after the variable (similar to how we declare
>> return types) we no longer have the issues with mis-parsing. Of
>> course, that's not how we declare parameter types currently. I think
>> we would need to permit it everywhere and deprecate the current syntax
>> with the type being prefixed. (By deprecate I mean in PHP 8 and not
>> remove it until PHP 9 or later)
>>
>> I would prefer that we shorten the `function` keyword to `fn`:
>>
>>     [fn($x) =3D> $x * 2]
>>
>> This preserves the shortness of the expression while providing
>> unambiguous, simple parsing. Of course, now we have a similar issue:
>> we have both `fn` and `function`.
>>
>> What concerns do you have about `fn($x) =3D> $x * 2` or `function($x) =
=3D>
>> $x * 2`? I will be writing a proper RFC later but I wanted to get
>> discussion going now.
>>
>>   [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference=
/Functions/Arrow_functions
>>   [2]: https://wiki.php.net/rfc/short_closures
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
> Hello,
>
> personally, as a purely userland dev, I feel that the correct syntax
> would be the "simplest" one - and that's imho the (Type &$x) =3D=3D> expr
>
> Or the version with ~> operator - I don't care which one gets in,
> althought I would rather see the =3D=3D> one. :)
>
> I understand that there might be some ambiguity in the parser that
> would need to be solved by backtracking, but for using the language,
> the "simplest" option should IMHO be the correct one. Also not
> introducing any more "stuff" (like new parameter types syntax) would
> be a plus.
>
> For the need to have a single parameter enclosed with ( ) - by
> thinking more and more about it, I think that having the one special
> case for not requiring parenthesis around parameters is pretty uselss,
> since it would have to be there anyways if you wrote the typehint.

I do not think it is feasible to make the parser do backtracking or
anything of that sort. How do others feel?

> PS: the [fn($x) =3D> $x * 2] seems ambigous, from reader's POV; key of
> the item is result of fn($x) and value is $x * 2? Also, it would be a
> huge BC break with not allowing you to name functions fn(), wouldn't
> it?

This is not a huge backwards compatibility break, no. It is a small
break. This is one reason `fn` is not necessarily what I will be
proposing and want to hear more feedback. Note that the `function`
version wouldn't be possible to be confused *at all*:

    // function($x) isn't allowed for function name
    // so this is very unambiguous
    [function($x) =3D> $x * 2];

Also note that using closures in array literals is not really that common.