Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54383
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain officechristmas.co.uk designates 188.39.46.83 as permitted sender)
Message-ID: <4E3AFE62.3080200@officechristmas.co.uk>
Date: Thu, 04 Aug 2011 21:17:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <4E3AF896.2090106@officechristmas.co.uk> <A1.D0.24235.37AFA3E4@pb1.pair.com>
In-Reply-To: <A1.D0.24235.37AFA3E4@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: An implementation of a short syntax for closures
From: jezz.g@officechristmas.co.uk (Jezz Goodwin)

On 04/08/2011 21:00, Matthew Weier O'Phinney wrote:
> On 2011-08-04, Jezz Goodwin<jezz.g@officechristmas.co.uk>  wrote:
>> --------------060805070009050707030403
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> Content-Transfer-Encoding: 7bit
>>
>> Hello PHP Internals,
>>
>> This is my first message to the list. I've been reading via the archive
>> since I read the 5.4RC1 announcement. (Keep up the great work guys - I'm
>> loving the new stuff)
>>
>> Up until now I haven't had anything to say that wasn't already being
>> talked about, but the topic of short hand syntax is of particular
>> interest to me.
>>
>> Before I start, I think I need to make clear that I am in general not a
>> fan of making cryptic code (ala perl). I tend to use long descriptive
>> variable names and try to make my code easy to read so that comments
>> aren't usually necessary.
>>
>> Saying that though, I am a big supporter of the new short hand array
>> syntax. From a grammatical point of view, I see no reason why my code
>> needs to be scattered with the word 'array'. The simple square brackets
>> ['a'=>'b'] I find just as easy to understand and they don't confuse me.
>> (unlike something along the lines of regex, that can easily confuse).
>>
>> I see the desire to wanting to remove the word function as a similar
>> issue. When you use inline functions a lot, your code is filled with
>> lots of the word 'function'. This word doesn't necessarily need to be
>> there for your code still to make sense.
>>
>> Also, on a similar vein of thought, if your function is only doing
>> something small, why do we need to put the word 'return' in there?
> Well, for one, it'd be a huge disconnect between the current behavior of
> functions and the new syntax. In PHP, if you have no explicit "return"
> in your function, a null is implicitly returned. If you were to change
> this so that whatever the value of the last assignment or line was is
> returned, we'd have a huge BC break -- even if this were only in
> lambdas.

I wasn't suggesting this to be the default action for functions / 
lambdas. You would have to specify that you wanted to return using => Eg:

:($x)=>$x+1;

returns $x + 1. where as:

:($x){ $x+1; }

still returns null

>
> I agree that shorter notation is often nice as it allows the syntax to
> get out of the way and potentially make code more readable. However,
> that's true only to a point -- if you go too far in the opposite
> direction, you end up with code that's unreadable as you have to inject
> context. I personally feel the proposed (by the original poster) lambda
> syntax falls in this category -- I found it _more_ difficult to
> understand the execution flow, and I suspect this was in large part
> because it stopped resembling traditional PHP syntax.
>
> Of the syntax changes you propose below, the only one that seems like it
> retains readability to me is the very first -- and even that one, I
> suspect, would cause some issues for the lexer.
>
>> I have been thinking of what syntax(s) could work to shorten the code
>> but not to make the code confusing. I am splitting up my ideas in to
>> separate sections. I think that if a short-hand function syntax is to be
>> accepted, it should be useful in many circumstances - eg, it shouldn't
>> necessarily be limited to one liners.
>>
>>
>>
>> Okay, here is a base example:
>>
>> $modify = function( $x )use( $my_constant ){ return $x + $my_constant; };
>>
>>
>> 1) REMOVING THE WORD 'function':
>>
>> One solution is to simply remove the word function completely:
>>
>> $modify = ( $x )use($my_constant ){ return $x + $my_constant; };
>>
>> On first glance, to me, this doesn't look like I'm starting to write a
>> function. I could perhaps be opening a bracket to do some maths. So,
>> what could be done to make it more obvious? I suggest using a character
>> to represent function. Personally I like colon:
>>
>> $modify = :( $x )use( $my_constant ){ return $x + $my_constant; };
>>
>> Now, I know this doesn't immediately scream function, but it is a
>> different/specific syntax which should hopefully lead to less confusion.
>>
>>
>>
>> 2) REMOVING THE WORD 'return':
>>
>> Okay, my function is still a bit wordy for what it's doing. How do we
>> remove return? I quite like the use of =>  that has been suggested in
>> previous posts.
>>
>> $modify = :( $x )use( $my_constant )=>  $x + $my_constant;
>>
>>
>>
>> 3) REMOVING THE WORD 'use':
>>
>> Personally I don't think use is causing a problem, I find it helps the
>> grammar of this function. If it was to go though, it could be replaced
>> with something like a colon:
>>
>> $modify = :( $x : $my_constant )=>  $x + $my_constant;
>>
>> Is this going too far? Is it now too cryptic?
>>
>>
>>
>> 4) REMOVING THE BRACKETS?
>>
>> In lots of the examples of short hand closures in other languages there
>> are no brackets. I think that might be going too far, but perhaps not:
>>
>> $modify = : $x : $my_constant =>  $x + $my_constant;
>>
>> Too much! This line simply confuses me!
>>
>>
>>
>> OTHER EXAMPLES
>>
>> So, personally I don't think shortening needs to go as far as 3 or 4.
>> But, I am a fan of 1 and 2.
>>
>> To demonstrate more how this might look, I'm using the code examples
>> Lazare used in his original post:
>>
>> // Mapping:
>> $a->select( function($x){ return $x->getName(); } );
>>
>> // Filtering:
>> $a->where( function($x)use($y){ return $x==$y; } );
>>
>> // Currying:
>> $add = function($x){ return function($y)use($x){ return $x+$y; }; };
>>
>>
>>
>> With my examples of shortening, these become:
>>
>> // Mapping:
>> $a->select( :($x)=>  $x->getName() );
>>
>> // Filtering:
>> $a->where( :($x)use($y)=>  $x==$y );
>>
>> // Currying:
>> $add = :($x)=>  :($y)use($x)=>$x+$y ;
>>
>>
>> Hmm... I don't like my currying example, it's starting to boggle my
>> mind. How about:
>>
>> $add = :($x)=>( :($y)use($x)=>$x+$y );
>>
>> Much better.
>>
>>
>>
>> Regardless of all of this, I actually don't find myself using too many
>> inline functions. (Not to the extent I was writing 'array' all over my
>> code anyway) - So I can't argue srongly about function shortening making
>> it's way in to PHP.
>>
>> Perhaps once we're all using inline functions on every other line of our
>> code there'll be a bigger demand for it!
>