Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88020
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55E77CA9.7050609@gmail.com>
References: <BLU436-SMTP13020F8CE8795C628BDC665E26B0@phx.gbl>
	<CAESVnVq9kBhK_uEH2-HvQN4Wv8DVSnwc9ukRjrQ0KNjUbaAD7g@mail.gmail.com>
	<55E77CA9.7050609@gmail.com>
Date: Thu, 3 Sep 2015 08:32:03 +0200
Message-ID: <CAB6YZux4uYG7u0XRc_56MWFo+8G_h_VZZbWhCDVqA7hdu5XSpg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
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 12:48 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
>
> So I would like to put forward for consideration these amendments to the
> proposal, in the spirit of compromise (in no particular order; numbers are
> just for reference in future discussion):
>
> Amendment 1. Only allow the single-expression form of the short syntax; full
> function bodies must be declared with the existing function(){ ... } syntax.
> This gives a clearer distinction between how the two syntaxes can be used.

This one sounds reasonable, but you'll probably get a RFC for almost
every upcoming version to allow the more complex bodies.

> Amendment 2. Make the ~> operator non-associative, so that lambdas returning
> lambdas would need an extra pair of brackets making the nesting explicit. To
> take one of Anthony's examples:
>
> function partial(callable $cb) {
>     return $left ~> ( $right ~> $cb($left, $right) );
> }
>
> It's now at least clearer that there are two different anonymous functions
> here, even if it's not entirely clear what they're trying to achieve...
>

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).

> Amendment 3. Make the parentheses around the argument list mandatory so that
> (if Amendment 1 is also adopted) there is only a single variant of the
> syntax, namely "( param list ) ~> expression".
>
>
> Amendment 4. Consider a syntax involving an explicit "use". This one
> requires a bit more exploration, but maybe something like:
> ( $a use $b ) ~> $a + $b
> or:
> ( $a ) use ( $b ) ~> $a + $b
>

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? I wouldn't mind the
mandatory ( ) around parameters, but at the same time I think that
it's an useless rule and makes the written code more "cluttered" (too
much ( and ) imho make the code less readable).


Btw. about your previous email and this syntax ending your career -
why would it? Reading the documentation and doing a mental note of
"simplified anonymous function declaration with optional ( ) if
there's just one paramater and automatically returning the expression
or having a whole function body enclosed in { }" shouldn't be a
problem? This is definitely not a "write-only" code.

If you are afraid the syntax will make the code less readable - look
at other languages (not for the sake of "they do it too", but for "how
does the code using it look like"). I can only speak about C#, and it
feels like it fits there - even though the language has more verbose
constructs and stuff. This should IMHO be a natural fit for PHP.

Regards
Pavel Kouril