# An implementation of a short syntax for closures

- Thread: https://externals.io/message/54381
- Original archive: https://news-web.php.net/php.internals/54381
- Started by Jezz Goodwin on 2011-08-04T19:52:54+00:00
- Messages: 9
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #54381 — Jezz Goodwin — 2011-08-04T19:52:54+00:00

URL: https://externals.io/message/54381#54381

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?

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!


Best regards,
Jezz Goodwin

---

## #54382 — Matthew Weier O'Phinney — 2011-08-04T20:00:52+00:00

URL: https://externals.io/message/54381#54382 · In reply to: #54381

> --------------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 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!


-- 
Matthew Weier O'Phinney
Project Lead            | matthew@zend.com
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

---

## #54383 — Jezz Goodwin — 2011-08-04T20:17:38+00:00

URL: https://externals.io/message/54381#54383 · In reply to: #54382

> 
> > […]
> 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.
>
> > […]

---

## #54384 — Sebastian Krebs — 2011-08-04T20:20:55+00:00

URL: https://externals.io/message/54381#54384 · In reply to: #54381

Just two examples, why I think, this is a not a good idea. Simple typos 
can produce hard to track errors. Its just confusing

$x = 4;
$y = ($x);{
     return $x*2;
}


// and

$x = 4;
$x = ($x)
{
     $y = $x*2;
}




> 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?
>
> 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!
>
>
> Best regards,
> Jezz Goodwin

---

## #54385 — Jezz Goodwin — 2011-08-04T20:34:57+00:00

URL: https://externals.io/message/54381#54385 · In reply to: #54384

In terms of thinking about typos, I'm sure there would be a solution to 
making pretty robust short hand lambdas.

I think a more valid discussion would be whether PHP should have a short 
hand lamda notation. A lot of talk on here is against there even being a 
short-hand version, whatever syntax it is.

I'm really trying to continue the discussion in to coming up with a good 
syntax everyone likes. If there is a good syntax maybe people against 
the idea might change their opinion.

Personally I think it would be a good addition to the language. As other 
people have pointed out, a lot of common languages have a syntax for 
short hand lambdas. Also with the popularity of technologies such as 
LinQ increasing, I can see small lambdas becoming more and more common.

In regards to typos, I don't think the following bit of code would be 
too easy to put a typo in to?:

// Mapping:
$a->select( :($x)=> $x->getName() );




> Just two examples, why I think, this is a not a good idea. Simple 
> typos can produce hard to track errors. Its just confusing
>
> $x = 4;
> $y = ($x);{
>     return $x*2;
> }
>
>
> // and
>
> $x = 4;
> $x = ($x)
> {
>     $y = $x*2;
> }

---

## #54386 — jerem.poulain@gmail.com — 2011-08-04T20:42:04+00:00

URL: https://externals.io/message/54381#54386 · In reply to: #54382

Hi every one,

This message is also my first one. I've been following internals for few
weeks now.

I really don't think adding more short syntax would be a good idea, at least
this one.

PHP is a very popular language for many reasons, it's C-like, easy readable.
We all had to read some code made by others, most of the time without any
comment. Even with big and complicated code, keywords like function and
return help understanding because you can identify some parts of code
quickly.

Most of developpers use an IDE which use syntax colors and autocompletion so
that writing and analysing code is not a big deal. It wouldn't be that easy
if too many short syntax had been implemented.

All the given examples show closures with one instruction. It would be a
nightmare with more lines...

Jérémy Poulain

2011/8/4 Matthew Weier O'Phinney <weierophinney@php.net>

> 
> > […]
>
> 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 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.
>
> > […]
>
>
> --
> Matthew Weier O'Phinney
> Project Lead            | matthew@zend.com
> Zend Framework          | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

---

## #54388 — johannes@schlueters.de — 2011-08-04T20:53:36+00:00

URL: https://externals.io/message/54381#54388 · In reply to: #54383

> :($x)=>$x+1;

":(" looks quite sad. I also assume you know that : is a division. In a
more complex situation this might, on first sight, be mistaken as a
division by $x or such.

Mind that a line of code typically is read way more often than written.
Readability matters. PHP in many areas makes a good thing by having
keywords here and there.

johannes

---

## #54390 — Jezz Goodwin — 2011-08-04T21:02:40+00:00

URL: https://externals.io/message/54381#54390 · In reply to: #54388

Haha, yes indeed. In fact my Thunderbird was changing them to sad 
smileys until I disabled emoticons!

Colon is one of many possibilities.

Your argument goes back to whether or not PHP should have short-hand 
lambdas in general. It's looking like the majority of people think it 
shouldn't.




> 
> > […]
> ":(" looks quite sad. I also assume you know that : is a division. In a
> more complex situation this might, on first sight, be mistaken as a
> division by $x or such.
>
> Mind that a line of code typically is read way more often than written.
> Readability matters. PHP in many areas makes a good thing by having
> keywords here and there.
>
> johannes

---

## #54392 — Stas Malyshev — 2011-08-04T21:54:05+00:00

URL: https://externals.io/message/54381#54392 · In reply to: #54390

Hi!


> Your argument goes back to whether or not PHP should have short-hand
> lambdas in general. It's looking like the majority of people think it
> shouldn't.

And really, PHP doesn't need more cryptic syntax. There are many things 
that PHP does need (like people fixing unit tests, though I know it's 
not as fun as discussing new cryptic syntax ;) but new cryptic syntax 
wouldn't really allow to do anything that can't be done right now. And 
saving keystrokes is not really big preference, especially for language 
like PHP. One should be spending much more time reading code and 
thinking about it than typing it anyway :)
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227