Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88147
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.155 cause and error)
To: Bob Weinand <bobwei9@hotmail.com>
References: <BLU436-SMTP13020F8CE8795C628BDC665E26B0@phx.gbl>
 <CAESVnVq9kBhK_uEH2-HvQN4Wv8DVSnwc9ukRjrQ0KNjUbaAD7g@mail.gmail.com>
 <55E77CA9.7050609@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <55F1E269.60403@telia.com>
Date: Thu, 10 Sep 2015 22:04: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: <55E77CA9.7050609@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. 00:48, skrev Rowan Collins:
> On 02/09/2015 22:49, Sara Golemon wrote:
>> Beautiful code is code that is easier to
>> maintain, and code that is easier to maintain is often more secure and
>> reliable.
>
> I think this is an important point. Obviously, "beauty" is subjective: 
> some people will find very verbose, English-like code easier to read; 
> others might try to squeeze as much information into one screenful as 
> possible, so they can see the whole program at a glance.
>
> At one extreme, SQL has mandatory words like the "AS" in "CAST(x AS 
> int)" just to "look more like English"; at the other, APL has symbols 
> all of its own with their own Unicode code points. Most languages aim 
> for some compromise in between.
>
>
> 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.
>
> 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...
>
> 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
>
>
> Perhaps there are other thoughts along these lines that could move the 
> proposal beyond a simple love/hate debate.
>
> Regards,
>
Any plans to incorporate any of the amendments above in the RFC?
Personally I favour amendment 3. One of your examples would be:
functionreduce(callable $fn){
return($initial)~>($input)~>{
     $accumulator=$initial;
         foreach($inputas$value){
             $accumulator=$fn($accumulator,$value);
         }
     return$accumulator;};
}

Or maybe I'm just overly familiar having function arguments
within parenthesis ;)

Regards, //Björn Larsson