Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88028
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)
References: <BLU436-SMTP13020F8CE8795C628BDC665E26B0@phx.gbl>
 <CAESVnVq9kBhK_uEH2-HvQN4Wv8DVSnwc9ukRjrQ0KNjUbaAD7g@mail.gmail.com>
 <55E77CA9.7050609@gmail.com>
 <CAB6YZux4uYG7u0XRc_56MWFo+8G_h_VZZbWhCDVqA7hdu5XSpg@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Message-ID: <55E81959.6040305@gmail.com>
Date: Thu, 3 Sep 2015 10:56:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CAB6YZux4uYG7u0XRc_56MWFo+8G_h_VZZbWhCDVqA7hdu5XSpg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [Discussion] Short Closures
From: rowan.collins@gmail.com (Rowan Collins)

Pavel Kouřil wrote on 03/09/2015 07:32:
> Amendment 2. Make the ~> operator non-associative

> Why? Once you read documentation about how the operator works and what
> it does, you will know it and writing the extra brackets seems
> superfluos. And woudn't this complicate the parser even more? Also, if
> you have no idea about functional programming whatsoever, this will be
> hard to grasp in any syntax form, but the syntax isn't the problem in
> that case (as I already said in previous email).

Yeah, maybe this one is just me - I just find right-associativity really 
hard to read, whatever it's purpose. Maybe it's because I've only ever 
read left-to-right languages.

As mentioned in a previous e-mail, when I look at "$a ~> $b ~> $c" it 
makes me think of a single chain where all the terms are somehow 
related, like "$a = $b = $c", rather than any kind of nesting. Maybe I'd 
get used to it, maybe it would be rare enough that I'd never need to.


> So you are taking a syntax that's supposed to be short and "clean" and
> making it more complex by the amedments 3 and 4?

No, I'm trying to think of compromises which address constructive 
criticisms people have made of the current proposal, such as the variety 
of syntax forms, and the implicit scoping of variables.

To be clear, these are not demands or anything like that, just 
suggestions of how to move the discussion beyond "here's the proposal, 
take it or leave it".


> Btw. about your previous email and this syntax ending your career -
> why would it?

That wasn't my e-mail, it was one I replied to. I'm not against this 
proposal, I'm genuinely trying to find ways forward with it.

Regards,
-- 
Rowan Collins
[IMSoP]