Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88031
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.154 cause and error)
To: Rowan Collins <rowan.collins@gmail.com>
References: <BLU436-SMTP13020F8CE8795C628BDC665E26B0@phx.gbl>
 <CAESVnVq9kBhK_uEH2-HvQN4Wv8DVSnwc9ukRjrQ0KNjUbaAD7g@mail.gmail.com>
 <55E77CA9.7050609@gmail.com>
 <CAB6YZux4uYG7u0XRc_56MWFo+8G_h_VZZbWhCDVqA7hdu5XSpg@mail.gmail.com>
 <55E81959.6040305@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Message-ID: <55E8264D.6060609@telia.com>
Date: Thu, 3 Sep 2015 12:51:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55E81959.6040305@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [Discussion] Short Closures
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)



Den 2015-09-03 kl. 11:56, skrev 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".
Really appreciate that! Like the idea but the variation in syntax forms
is a bit confusing. Maybe one start with a very simple function and as
as you expand it the syntax form needs to change which I think is a
drawback.

Regards , //Björn Larsson