Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88043
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55E81959.6040305@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>
Date: Fri, 4 Sep 2015 08:44:07 +0200
Message-ID: <CAB6YZuwimHWkh8ddvkagmXRQVCK-joUSmMYKKxxjx22BbktSRg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] Short Closures
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

On Thu, Sep 3, 2015 at 11:56 AM, Rowan Collins <rowan.collins@gmail.com> wr=
ote:
> Pavel Kou=C5=99il 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 re=
ad
> left-to-right languages.
>
> As mentioned in a previous e-mail, when I look at "$a ~> $b ~> $c" it mak=
es
> me think of a single chain where all the terms are somehow related, like =
"$a
> =3D $b =3D $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.

Yeah, my guess is that most developers would use this just for more
simple array_map/array_filter/etc. usage, so you probably wouldn't
encounter this use case "in the wild" much.

But imagine having something like this (combined with your #3):

function partial($cb) { return ($left) ~> (($right) ~> $cb($left, $right));=
 }

I hope I got the parenthesination correct, because now there's a ton
of parenthesis and it's even harder to read (and write). If I had to
choose between amendments #3 and #2, I'd go with #3 just for the sake
of consistency - but I definitely wouldn't choose both of them
simultaneously.

But even just #3 seems kinda "harder" to read than the form without
any parenthesis.

function partial($cb) { return ($left) ~> ($right) ~> $cb($left, $right); }

I know the parenthesis are optional in just one scenario, but I'd
argue it's probably the most common one.

>> 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 critici=
sms
> 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 suggestion=
s
> of how to move the discussion beyond "here's the proposal, take it or lea=
ve
> it".
>

Yes, I hope everyone is trying to move the discussion forwards,
because I would love to see this in some reasonable form in PHP.

In my personal order of "most reasonable" ammendments, it would be #1
> #3 > #2 > #4. The #1 I could even see getting positive feedback,
because for everything longer than one statement, people can use the
function () { ... } declaration (unlike in some other languages).

>
>> 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.
>

Oh, really sorry! I read a lot of those emails at the same time and
somehow got two emails mixed up together! :)


Regards
PK