Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99288
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.156 cause and error)
To: Levi Morrison <levim@php.net>
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
 <alpine.DEB.2.20.1705302038520.2232@singlemalt.home.derickrethans.nl>
 <d6741c05-f014-c23a-ced8-2cddd76a078b@telia.com>
 <CAFMT4NpJqDg1W-jSXFcgL3PGj--gbr+QTFdXAu+z-WK1xjMdHA@mail.gmail.com>
Message-ID: <d810b4f4-ba3e-c90f-cb26-aa5b704b69b1@telia.com>
Date: Wed, 31 May 2017 00:46:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAFMT4NpJqDg1W-jSXFcgL3PGj--gbr+QTFdXAu+z-WK1xjMdHA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2017-05-31 kl. 00:26, skrev Levi Morrison:

> On Tue, May 30, 2017 at 3:37 PM, Björn Larsson
> <bjorn.x.larsson@telia.com> wrote:
>> Den 2017-05-30 kl. 21:40, skrev Derick Rethans:
>>
>>> 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