Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88606
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
References: <CAFMT4NrOsRm_6Qb11cbtsq0H-_OYugu-u-3Q+EC9J3Ze9BNAYg@mail.gmail.com> <5606D0EB.3060106@gmail.com> <CAEYWF=7-=ToVrBK7y1NcOtSU9iB5BpK=3iuyX-5i3GkGvMow-A@mail.gmail.com> <CAFMT4NqA-ZrhUuGmhiCyzVAwd0s=ecQ3fz5EkhXv2F_q-w5h+g@mail.gmail.com> <560D0F94.8060009@gmail.com> <op.x5tqi5uhc9evq2@nikita-300e4c-300e5c-300e7c> <560D282F.6060202@gmail.com>
Date: Thu, 01 Oct 2015 17:58:28 +0300
Cc: "rowan.collins@gmail.com" <rowan.collins@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.x5t07q2ic9evq2@nikita-300e4c-300e5c-300e7c>
In-Reply-To: <560D282F.6060202@gmail.com>
User-Agent: Opera Mail/12.16 (Linux)
Subject: Re: [PHP-DEV] Arrow function expressions in PHP
From: inefedor@gmail.com ("Nikita Nefedov")

On Thu, 01 Oct 2015 15:33:51 +0300, Rowan Collins  
<rowan.collins@gmail.com> wrote:

> That's not how Rasmus expressed it  
> [http://marc.info/?l=php-internals&m=144107616411299&w=2]:
>
>  > I made a very deliberate decision In the very first implementation of  
> PHP to avoid scope side-effects like this. Inside a function everything  
> is local unless explicitly declared not to be. This has carried through  
> for the past 20+ years in slightly different ways, but the basic rule  
> has stayed consistent even for closures.

Ok, it proves that it's not evolutionary that scopes aren't chained.  
Taking my words back.


> It is a tool for making them shorter, yes, but it is not the only way,  
> and it comes with a cost of changing established behaviour. Again, look  
> at C++'s lambda syntax - it is much shorter than PHP's, but requires a  
> list of all variables from the outer scope being captured.

C++11 doesn't *require* the list of all variables, but it does require  
explicit "wildcard" ([=] for copy semantics, [&] for capturing by  
reference).
But C++ is not the best place for picking up syntax choices, quite frankly  
it's one of the least readable languages in a way that it allows you to  
write very cryptic code easily (but still allows to write perfectly  
readable code as well).
I'm not aware of reasons why ISOCPP decided that automatic capture should  
be disabled by default, maybe it was because it was hard to decide whether  
it should default to by-value or to by-reference semantics, or maybe []  
tokens were needed because of parsing limitations.


> You've picked on one syntax I explicitly labelled as "a straw man", and  
> one idea which was proposed by somebody else a few hours ago, and use  
> those to somehow dismiss the whole idea of a short syntax which lists  
> captured variables. I have come up with about a dozen different ideas in  
> various parts of this discussion, and could list dozens more. They would  
> all have their pros and cons, but I don't see how you can dismiss the  
> whole concept, UNLESS you consider the auto-capture to be an end in its  
> own right, rather than "just a way of making it shorter".

I don't think there was a dozen of different ideas, I could only find  
those about `lambda(arg-list; use-list; expression)` and variations of it  
with different keywords and different return-type syntax.
I do understand that this is quite subjective, but neither this syntax nor  
`fn(arg-list; use-list) expression` look obvious and easily readable to me.

And one thing that makes auto capture much better choice than explicit  
capture (as it've been said a couple of times already) is partial  
application:

     $mul = fn($x) => fn($y) => fn($z) => $x * $y * $z;

Looks simpler than:

     $mul = fn($x) => fn($y; $x) => fn($z; $x, $y) => $x * $y * $z;