Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88609
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <op.x5t07q2ic9evq2@nikita-300e4c-300e5c-300e7c>
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>
	<op.x5t07q2ic9evq2@nikita-300e4c-300e5c-300e7c>
Date: Thu, 1 Oct 2015 12:28:08 -0400
Message-ID: <CAAyV7nE=LdG==0n0XLS0mSzWO+ZC=-CVBoFht4CYpS6r4RMgeA@mail.gmail.com>
To: Nikita Nefedov <inefedor@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>, 
	"rowan.collins@gmail.com" <rowan.collins@gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Arrow function expressions in PHP
From: ircmaxell@gmail.com (Anthony Ferrara)

Nikita and all,

On Thu, Oct 1, 2015 at 10:58 AM, Nikita Nefedov <inefedor@gmail.com> wrote:
> 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.

The problem is that semicolons are non-obvious, especially in a
context where commas are used (and traditionally used).

Example, tell the difference quickly between

fn($a, $b; $c) => $a + $b + $c;

and

fn($a; $b, $c) => $a + $b + $c.

At a glance, they are identical. You have to actually look at each
item to realize that there's a difference. At least with use() there's
a syntactical separator there to draw your eye to the contextually
relevant information.