Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98199
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.162 cause and error)
MIME-Version: 1.0
In-Reply-To: <f630636f-d616-45f1-cb01-7b5805b2667d@garfieldtech.com>
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
 <CAFMT4Nq_vbCRmMZ2OSDN7_VqGG6UR6PTNevz3DWLF9K8MODMYg@mail.gmail.com>
 <CAFMT4NoxVT3JGLmT-8Vj5R4c-h-m9xK20nG3vQHyBKx3aNX3Og@mail.gmail.com> <f630636f-d616-45f1-cb01-7b5805b2667d@garfieldtech.com>
Date: Sat, 4 Feb 2017 22:08:09 +0100
Message-ID: <CANUQDCjVjHycSY9xKbU=WDfTcZtEJ5omhU+uMEnj5CcOzg2Yuw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114030a4afd3050547bacb32
Subject: Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions
From: me@kelunik.com (Niklas Keller)

--001a114030a4afd3050547bacb32
Content-Type: text/plain; charset=UTF-8

2017-02-04 21:49 GMT+01:00 Larry Garfield <larry@garfieldtech.com>:

> 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.
>

I'd say the capture semantics aren't the first thing to be concerned with.
First you want to know it's a anonymous function with one parameter,
exactly what "function ($a)" tells you. For normal closures, "use ($n)"
tells you it imports $n from the parent scope into the body enclosed in
braces. For short closures, you see the "=>" and an expression and know
that any outer variable you use will be imported from the parent scope.

Regards, Niklas


> 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
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a114030a4afd3050547bacb32--