On Mon, Sep 28, 2015 at 3:38 PM, Pavel Kouřil <pajou...@gmail.com> wrote:
> On Sat, Sep 26, 2015 at 6:17 PM, Levi Morrison <le...@php.net> wrote:
>> (Email in gist format:
>> https://gist.github.com/morrisonlevi/fa7984c04ff176b5a87c)
>>
>> In EcmaScript 2015 (ES6) the expression `(x) => x * 2` means to create
>> an anonymous function with one parameter `x` that will return `x * 2`.
>> For example:
>>
>> (x) => 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 = [
>> "Hydrogen",
>> "Helium",
>> "Lithium",
>> "Beryllium"
>> ];
>>
>> var a2 = a.map(function(s){ return s.length }); // pre-ES6
>>
>> var a3 = a.map((s) => 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) => $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) => $x * 2;
>>
>> This is why Bob Weinand [proposed][2] using `~>` instead of `=>`.
>> However, if we allow type declarations there is another issue. In the
>> definition `(Type &$x) => expr` the `(Type &$var)` part 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 it will error and it doesn't know which rule to pick. Changing
>> the token from `=>` to `~>` doesn't affect this issue.
>>
>> We could solve the first ambiguities with prefering the current
>> meaning with `key => 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) => $x * 2];
>>
>> // clearly yields an anonymous function
>> yield function($x) => $x * 2;
>>
>> // clearly an anonymous function
>> function(Type &$x) => 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) => 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) => $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) => $x * 2` or `function($x) =>
>> $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) ==> expr
>
> Or the version with ~> operator - I don't care which one gets in,
> althought I would rather see the ==> 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) => $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) => $x * 2];
Also note that using closures in array literals is not really that common.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
