Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98196
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
To: internals@lists.php.net
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
 <CAFMT4Nq_vbCRmMZ2OSDN7_VqGG6UR6PTNevz3DWLF9K8MODMYg@mail.gmail.com>
 <CAFMT4NoxVT3JGLmT-8Vj5R4c-h-m9xK20nG3vQHyBKx3aNX3Og@mail.gmail.com>
Message-ID: <f630636f-d616-45f1-cb01-7b5805b2667d@garfieldtech.com>
Date: Sat, 4 Feb 2017 14:49:53 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAFMT4NoxVT3JGLmT-8Vj5R4c-h-m9xK20nG3vQHyBKx3aNX3Og@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions
From: larry@garfieldtech.com (Larry Garfield)

On 02/03/2017 11:53 AM, Levi Morrison wrote:
>
>> Thanks to everyone who has participated in the discussion thus far.
>> Primarily the feedback has been directed at the `fn` keyword. Let me
>> provide two benefits and drawbacks of using `fn` as a keyword:
>>
>>    1. `fn` is searchable in search engines and in our manual
>>    2. Is more intuitive than just syntax
>>
>> However, `fn` does have downsides:
>>
>>    1. Can break existing code
>>    2. We already have a similar keyword `function`
>>
>> To that end, I'd like to gauge interest in a pure syntax based
>> alternative that is similar to Rust and Ruby.
>> Instead of:
>>
>>      fn(params) => expr
>>
>> What about:
>>
>>      |params| => expr
>>
>> This trades the advantages of the keyword for the advantages of pure
>> syntax, and happens to be two characters shorter. To be explicit:
>>
>>      1. Preserves 100% backwards compatibility
>>      2. Avoids having two keywords that both mean "function"
>>      3. Is not easily searchable in engines or in the manual
>>      4. Is a tad bit shorter
>>
>> What do you think, Internals?
> One more thing: I'd like to re-emphasize that the syntax that
> JavaScript uses and the one that HHVM/Hack uses are ambiguous in the
> current class of our grammar. The following will not work unless we
> move to a more powerful grammar and parser class:
>
>      (params) => expr
>      (params) ==> expr
>
> This is why an un-ambiguous prefix is necessary: the prefix breaks the
> ambiguities. The syntax I have suggested in the RFC and the one I
> suggested just now are not ambiguous because distinct prefixes:
>
>      fn(params) => expr
>      |params| => expr
>
> I look forward to more discussion!

Off hand, either of the above options would be acceptable to me. The 
union type concern is a valid one, but as noted I don't know how much of 
an issue that would be in practice even if we ever did get union types.  
(Now, if we also added defined type aliases... :-) )

I am definitely not a fan of reusing `function`.  The way I see it, the 
point of a short-closure is to take a simple expression and wrap it into 
a function so that it can be plugged into a function context.  I don't 
even think of it in the same way I would a named function/method, more 
casting an expression to  a function.

Additionally, to the point that was raised about developers being able 
to understand syntax reused in different context, that's true... if the 
context is in fact different.  A bitwise AND and a reference are 
extremely different situations so there's no reason for my brain to 
expect both to mean the same thing.  One is never a viable substitute 
for the other.

In contrast, however, we're talking about two different syntaxes for 
defining anonymous functions that have different closure semantics. 
Reusing `function` would mean:

$n = 2;

$x = function ($a) use ($n) { return $a * $n; }
$y = function ($a) => $a * $n;

Are equivalent.  But in order to know what the capture semantics are I 
can't tell from the start of the expression.  I have to look halfway 
down the line to know what the behavior is going to be for these two 
extremely similar actions.

In contrast:

$n = 2;

$x = function ($a) use ($n) { return $a * $n; }
$y = fn($a) => $a * $n;
$z = |$a| => $a * $n;

I in versions $y and $z, I can tell right from the beginning of the line 
which variant of "anonymous function capture logic" I will be dealing 
with.  I know from character 1 or 2, not character 12.

And then there's the extra typing and visual space taken up, which is 
not something to dismiss entirely.  Also, as someone else mentioned this 
syntax *seems* like it would support nesting. Compare the following:

$x = function($a) => function($b) => function($c) => $a * $b * $c;
$y = fn($a) => fn($b) => fn($c) => $a * $b * $c;
$z = |$a| => |$b| => |$c| => $a * $b * $c;

print $x(1)(2)(3); // prints 6

Which of these is more readable?  Id' argue it's not $x.

--Larry Garfield