Hello everyone.
I am new to the php-internals list. I have joined because I have
implemented a feature that I would like to be included in the php
language: a shorter syntax for lambdas. I am going to briefly present
it here. Apologies for the long (and yet incomplete) e-mail. I am
ready to write a more complete RFC in the wiki, however, I would
appreciate having some directions for that. Do I have to ask for
permission first? Is it open to anyone to submit an RFC?
- NECESSITY:
This feature was briefly discussed in this list about a month ago:
http://marc.info/?t=130926918200003&r=1&w=2.
It is also one of the asked (and upvoted) features in the open stack
overflow's discussion:
http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php.
Finally, I have written a small and probably incomplete article in my
blog about the necessity of a shorter syntax for lambdas:
http://linepogl.wordpress.com/2011/07/09/on-the-syntax-of-closures-in-php/
- THE CURRENT SYNTAX
I give 3 examples with the current syntax:
// 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; }; };
In my opinion, the above code is not easily readable. Yet, those
examples are not very complicated. The first two are samples of
elegant LINQ-style code while the last one can be found in the first
pages of any functional programming tutorial.
- PROPOSED SYNTAX
The syntax I propose and I have already implemented is this:
// Mapping:
$a->select( | $x |=> $x->getName() );
// Filtering:
$a->where( | $x : $y |=> $x==$y );
// Currying:
$add = | $x |=> | $y : $x |=> $x+$y;
- ADVANTAGES
a. The code is more readable (see more in my blog if you are not
convinced about that).
b. The syntax is backwards compatible. The short lambda and the longer
equivalent are interchangeable.
c. Variable scoping works exactly like in the longer version. There is
nothing new but syntactic sugar.
d. Lambda expressions are searchable. The |=> operator is unique.
e. The |=> operator is similar to =>. That's good because they both
relate to mapping. In addition, the : operator is similar to :: and
that's also good because they both relate to scoping.
f. The implemented syntax supports type hinting, passing by reference
and return by reference. There is also an option to fall back to a
statement block if the single return statement is not enough.
Therefore is a complete alternative to the existing syntax.
- DISADVANTAGES
a. The short syntax is clear and readable, but can become confusing
when used in the wrong places. Yet, isn’t this the case with every
feature?
b. A lambda without arguments conflicts with the logical or operator.
A way to avoid this is to insert whitespace between the two pipes, but
this breaks the invariant that whitespace is not important in PHP.
Although this use case is not ideal for short lambdas, it can be fixed
at the compiler level by introducing the rather long operator ||=>.
c. The newly introduced feature of static closures is not yet
supported. The short lambdas behave like dynamic closures for the time
being.
You can download the patch on the 5.4 branch from here:
https://bitbucket.org/linepogl/php_short_closures/downloads/short_closures_syntax_0.1_php54.diff
I have posted a more complete presentation here:
http://linepogl.wordpress.com/2011/08/04/short-closures-for-php-an-implementation/
I am ready to give more examples and to further defend my proposal.
However as I am new to your community, I would like to have some
directions on the way I should continue.
Kind regards,
Lazare INEPOLOGLOU
Ingénieur Logiciel
$add = | $x |=> | $y : $x |=> $x+$y;
This does not seem to match the syntax of any language I know of so
people are going to have a hard time figuring out what this does. It's
not even clear that |=> is a new operator there due to the dangling |,
which as you say conflicts with the regular | operator. Plus it is only
useful in one limited type of trivial closure usage.
In PHP we try really hard not to invent new unfamiliar syntax. We try to
stick with things that have some basis in either the existing syntax or
in other popular languages that the average PHP developer might be
exposed to.
-Rasmus
Hi,
I've always thought that just supressing the "function" keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40
Regards,
David
$add = | $x |=> | $y : $x |=> $x+$y;
This does not seem to match the syntax of any language I know of so
people are going to have a hard time figuring out what this does. It's
not even clear that |=> is a new operator there due to the dangling |,
which as you say conflicts with the regular | operator. Plus it is only
useful in one limited type of trivial closure usage.In PHP we try really hard not to invent new unfamiliar syntax. We try to
stick with things that have some basis in either the existing syntax or
in other popular languages that the average PHP developer might be
exposed to.-Rasmus
Hi!
I've always thought that just supressing the "function" keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40
My opinion is that when almost any mix of alphanumeric and
non-alphanumeric characters becomes a valid syntax in the language, it's
taking it a bit too far :)
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hello !
I've always thought that just supressing the "function" keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40
Huge +1 for that.
Code using closures will be more readable.
$add = | $x |=> | $y : $x |=> $x+$y;
Not sure that it's really readable.
Moreover, it's more Perl/Ruby way than PHP way.
Best regards,
Fred
--
Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
Blog : http://blog.mageekbox.net
Twitter : http://twitter.com/mageekguy
Hello,
$add = | $x |=> | $y : $x |=> $x+$y;
Not sure that it's really readable.
This is not the most trivial example. In my blog, there is a small
sub-section where I explain why this is more readable than an implementation
with the current syntax. See under "Readability" and "A more complicated
example".
http://linepogl.wordpress.com/2011/08/04/short-closures-for-php-an-implementation/
:-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
Le 4 août 2011 10:50, Frédéric Hardy frederic.hardy@mageekbox.net a écrit
:
Hello !
I've always thought that just supressing the "function" keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40Huge +1 for that.
Code using closures will be more readable.$add = | $x |=> | $y : $x |=> $x+$y;
Not sure that it's really readable.
Moreover, it's more Perl/Ruby way than PHP way.Best regards,
Fred--
Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
Blog : http://blog.mageekbox.net
Twitter : http://twitter.com/mageekguy
Good morning Rasmus,
Thank you for your interest. This is just a proposal that I have tested and
works. Of course, the final syntax can be different. Syntax is always a
matter of taste :-)
it is only useful in one limited type of trivial closure usage
This trivial usage is actually the most common one. A single-return closure
can be used for sorting, mapping, filtering, lifting, folding, comparing,
validating, formatting, lazy-loading etc. which cover the majority of the
tasks a PHP programmer does everyday. The popular LINQ library is just an
example of the power of this kind of closures.
The only case that these closures are not useful is asynchronous
(event-driven) programming. However, PHP is single threaded and usually
delegates the user interface to javascript, and therefore, two major needs
for asynchronous programming are eliminated.
In PHP we try really hard not to invent new unfamiliar syntax.
I have done some research before posting and it seems that the proposed
syntax is not at all uncommon. For example, here is the same comparer
written in a variety of languages:
Proposed for PHP:
| $x , $y |=> $x - $y
C#:
( x , y )=> x - y
Haskell:
\ x y -> x - y
Python:
lambda x y: x - y
OCaml, F#:
fun x y -> x - y
StandardML:
fn x y => x - y
There are many similarities here. In all of the above examples, there is no
return and no curly brackets. In addition, all expressions begin with a
token and separate the arguments from the returning expression with another
token.
Kind regards,
Lazare INEPOLOGLOU
Ingénieur Logiciel
2011/8/4 Rasmus Lerdorf rasmus@lerdorf.com
$add = | $x |=> | $y : $x |=> $x+$y;
This does not seem to match the syntax of any language I know of so
people are going to have a hard time figuring out what this does. It's
not even clear that |=> is a new operator there due to the dangling |,
which as you say conflicts with the regular | operator. Plus it is only
useful in one limited type of trivial closure usage.In PHP we try really hard not to invent new unfamiliar syntax. We try to
stick with things that have some basis in either the existing syntax or
in other popular languages that the average PHP developer might be
exposed to.-Rasmus
Lazare Inepologlou wrote:
Thank you for your interest. This is just a proposal that I have tested and
works. Of course, the final syntax can be different. Syntax is always a
matter of taste :-)
As much as I love the idea, I have to agree that using | doesn't really
make sense here and actually makes the readability worse, IMO. However,
I can't really think of a better operator. ( $x ) => $x + 1 for example
would be ambiguous if used in an array definition, but is otherwise the
best in terms of readability.
--
Ryan McCue
<http://ryanmccue.info/
Lazare Inepologlou wrote:
Thank you for your interest. This is just a proposal that I have tested and
works. Of course, the final syntax can be different. Syntax is always a
matter of taste :-)As much as I love the idea, I have to agree that using | doesn't really
make sense here and actually makes the readability worse, IMO. However,
I can't really think of a better operator. ( $x ) => $x + 1 for example
would be ambiguous if used in an array definition, but is otherwise the
best in terms of readability.
If you go there you can also allow more complex statements and re-use
symbols used to group statements, using a syntax like
( $x ) { $x + 1; }
Oh wait - now we've reached a point which was mentioned in this thread
already "allow to drop the function keyword".
Back when I proposed to drop "function" a key argument was that people
wanted an easy way to grep for function declarations. I accepted the
validity of that concern and think this might be a case here, too. The
difference of these few characters is not that much but the keyword
gives a clear guidance what's going on, else you might end up with a
long list of random characters next to each other ...
johannes
... ( $x ) => $x + 1 for example would be ambiguous if used in an array definition, but is otherwise the best in terms of readability.
... people wanted an easy way to grep for function declarations
A new and unique operator (like the |=> I have proposed) is a solution
that works because:
- A lambda expression can be part of other expressions, like arrays.
Therefore, we cannot reuse =>, or ->. - Multiple lambda expressions can be chained. The operator must have
very low precedence and it be right associative. - Lambdas should be grep-able.
For those who would like to try other syntaxes that could work in PHP,
I suggest a simple and creative way to approach this. All we need is 3
operators:
OP_A args OP_B lexical_vars OP_C expr
Operator OP_C ought to have the above properties (unique, low
precedence, right associative). On the other hand there are no
restrictions about OP_A and OP_B and we can reuse existing ones as
long as they don't conflict and they look nice.
:-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2011/8/4 Johannes Schlüter johannes@schlueters.de:
Lazare Inepologlou wrote:
Thank you for your interest. This is just a proposal that I have tested and
works. Of course, the final syntax can be different. Syntax is always a
matter of taste :-)As much as I love the idea, I have to agree that using | doesn't really
make sense here and actually makes the readability worse, IMO. However,
I can't really think of a better operator. ( $x ) => $x + 1 for example
would be ambiguous if used in an array definition, but is otherwise the
best in terms of readability.If you go there you can also allow more complex statements and re-use
symbols used to group statements, using a syntax like( $x ) { $x + 1; }
Oh wait - now we've reached a point which was mentioned in this thread
already "allow to drop the function keyword".Back when I proposed to drop "function" a key argument was that people
wanted an easy way to grep for function declarations. I accepted the
validity of that concern and think this might be a case here, too. The
difference of these few characters is not that much but the keyword
gives a clear guidance what's going on, else you might end up with a
long list of random characters next to each other ...johannes
... ( $x ) => $x + 1 for example would be ambiguous if used in an array definition, but is otherwise the best in terms of readability.
... people wanted an easy way to grep for function declarations
A new and unique operator (like the |=> I have proposed) is a solution
that works because:
Please stop that, it's not funny anymore.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime profiling for PHP
+1 - think everybody'd want their functions to be searchable and searching
for complex patterns like "(function)|(|=>)" would really be a headache.
Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic?
2011/8/4 Antony Dovgal tony@daylessday.org
... ( $x ) => $x + 1 for example would be ambiguous if used in an array
definition, but is otherwise the best in terms of readability.
... people wanted an easy way to grep for function declarations
A new and unique operator (like the |=> I have proposed) is a solution
that works because:Please stop that, it's not funny anymore.
--
Wbr,
Antony Dovgalhttp://pinba.org - realtime profiling for PHP
Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic?
No. I don't see at all why we need this, just like I don't see why we
needed an alternative (short) syntax for arrays. This kind of syntax
additions that add no functionality, should not be in PHP.
Derick
Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic?
No. I don't see at all why we need this, just like I don't see why we
needed an alternative (short) syntax for arrays. This kind of syntax
additions that add no functionality, should not be in PHP.
Yes, I believe we should stop this stream of alternative syntax proposals and concentrate
on fixing existing functionality instead of adding less readable ways to do the same thing.
I would really like to keep PHP code easily readable, not to turn it into perl-ish write-only gibberish.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime profiling for PHP
Btw, am I the only one to whom the proposed syntax seems kinda
hieroglyphic?
No. I don't see at all why we need this, just like I don't see why we
needed an alternative (short) syntax for arrays. This kind of syntax
additions that add no functionality, should not be in PHP.
Yes, I believe we should stop this stream of alternative syntax proposals
and concentrate on fixing existing functionality instead of adding less readable ways to do
the same thing. I would really like to keep PHP code easily readable, not to turn it into
perl-ish write-only gibberish.
100% agreed, both about the cryptic nature of the proposed syntax and
the need to focus on fixing existing issues. Strong -1 on a new
syntax.
The current PHP syntax for closures is the second-best one I've ever
used, IMHO. Clear, readable, explicit. My all-time favorite syntax is
that favored by Objective-C:
^ [returntype] ([params]) { code; }
The compiler figures out at build time which lexical stuff to capture,
and in most cases can infer the optional return type. I'd kinda love a
^ (params) use (captures) { code; } syntax in PHP, but nothing any
less wordy than that, and I'd hardly consider it any kind of priority.
On Thu, Aug 4, 2011 at 1:47 PM, Gwynne Raskind gwynne@darkrainfall.orgwrote:
Btw, am I the only one to whom the proposed syntax seems kinda
hieroglyphic?
No. I don't see at all why we need this, just like I don't see why we
needed an alternative (short) syntax for arrays. This kind of syntax
additions that add no functionality, should not be in PHP.
Yes, I believe we should stop this stream of alternative syntax proposals
and concentrate on fixing existing functionality instead of adding less
readable ways to do
the same thing. I would really like to keep PHP code easily readable, not
to turn it into
perl-ish write-only gibberish.100% agreed, both about the cryptic nature of the proposed syntax and
the need to focus on fixing existing issues. Strong -1 on a new
syntax.
Aye, just realized watching the |=> reminded me of perl... say, I think that
is what an aneurysm feels like.
On Thu, Aug 4, 2011 at 1:47 PM, Gwynne Raskind gwynne@darkrainfall.orgwrote:
Btw, am I the only one to whom the proposed syntax seems kinda
hieroglyphic?
No. I don't see at all why we need this, just like I don't see why we
needed an alternative (short) syntax for arrays. This kind of syntax
additions that add no functionality, should not be in PHP.
Yes, I believe we should stop this stream of alternative syntax proposals
and concentrate on fixing existing functionality instead of adding less
readable ways to do
the same thing. I would really like to keep PHP code easily readable, not
to turn it into
perl-ish write-only gibberish.100% agreed, both about the cryptic nature of the proposed syntax and
the need to focus on fixing existing issues. Strong -1 on a new
syntax.
Aye, just realized watching the |=> reminded me of perl... say, I think that
is what an aneurysm feels like.
One of the downsides to a language like perl was its Readability,
fancy magic symbols and lack of readability in its source code. PHP
has the opposite, very clear and readable C-like code. If PHP moves
towards a more magic syntax language then it would be
counter-productive.
Closures are quirky enough to wrap your eyes/mind around. Making these
more cryptic is very counter-productive.
Like mentioned, the amount of typing is not a problem, its more so
waiting on things to transfer, commit..etc
Very big -1 for me on this one. Please don't let a plethora of PHP
devs release code with this syntax.
Regards,
Paul Dragoonis.
Hi all :-),
$add = | $x |=> | $y : $x |=> $x+$y;
This does not seem to match the syntax of any language I know of so
people are going to have a hard time figuring out what this does. It's
not even clear that |=> is a new operator there due to the dangling |,
which as you say conflicts with the regular | operator. Plus it is only
useful in one limited type of trivial closure usage.
This syntax reminds me the “block lambda syntax”, presented on the
ECMAScript's wiki [1] about the future of ECMAScript6. It seems they
tend to choose the “arrow function syntax” [2], which is more natural
and more readable. You can found pros and cons on the wiki, along with a
lot of use cases/examples (including rebinding this!).
For a quicker introduction to these two short syntaxes, I would suggest
you to read the conference “FalsyValues” [3], from slide 31 to 36,
recently given by Dmitry Soshnikov about the future of ECMAScript 6 (all
the conference is a beauty, a must-read).
In PHP we try really hard not to invent new unfamiliar syntax. We try to
stick with things that have some basis in either the existing syntax or
in other popular languages that the average PHP developer might be
exposed to.
+1. It must be the result of a long reflection and we should get a large
vote from the community before choosen one syntax.
Best regards.
[1] http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
[2] http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
[3]
http://www.slideshare.net/dmitrysoshnikov/falsyvalues-dmitry-soshnikov-ecmascript-6
--
Ivan Enderlin
Developer of Hoa Framework
http://hoa.42/ or http://hoa-project.net/
Member of HTML and WebApps Working Group of W3C
http://w3.org/
2011/8/4 Lazare Inepologlou linepogl@gmail.com:
Hello everyone.
I am new to the php-internals list. I have joined because I have
implemented a feature that I would like to be included in the php
language: a shorter syntax for lambdas. I am going to briefly present
it here. Apologies for the long (and yet incomplete) e-mail. I am
ready to write a more complete RFC in the wiki, however, I would
appreciate having some directions for that. Do I have to ask for
permission first? Is it open to anyone to submit an RFC?The stuff...
Absolutely against such a syntax. Just try to imagine that you have to
actually not only write code, but you have to edit it and it can be
written by someone else.
The syntax we have right now is a bit wordy (is there such a word? :)
), but it makes code easily readable and formatted. Consider
JavaScript - it has function keyword for lambdas and no one is
complaining. Besides it lets you to indent your code beautifully:
$a->select(function($x) {
return $x->getName();
});
Or like this:
call_some_function(
$param1,
$param2
function ($x, $y) {
return $x * $y;
}
);
And so on.
If you write it in one line - it will become ugly one way or other no
matter the syntax.
Just make a Live Template (or whatever it's called in your IDE) for
somethink like "labd" => function (#vars#) { #body } for auto-complete
and be happy.
Is PHP still going the KISS way? PHP does not have different syntax's
for same things except few exceptions witch make sense and didn't
allowed such additions in the past. Please, can I ask the core team to
stay on the same line in the future :)
Oh, and I forgot one more thing:
As I read the internals, I noticed many times that PHP lexer is
somewhat limited in it's capabilities and sometimes the features are
dropped because of this issue.
It can be the case that the can be ambiguous and it will be just
impossible to add at this stage.
As Ryan McCue pointed out in his example - there can be a problem with
arrays. And so on. Use cases are not just limited to declaring a
lambda as a function callback or assigning it to a variable. Creatinx
syntax that just looks odd for the language like those | probably will
not be accepted by the community because it looks out of place.
my 2 cents
From your blog post:
All in all, I have tried to eliminate the syntax noise by
reducing the key strokes in the the non-significant parts
of the expression is typing time really the bottleneck for
productivity
Is typing really the bottleneck for developers these days? I must suck
then. I spend most of my day thinking or waiting on version control,
testing and deploy applications, not typing.
Brian.
http://brian.moonspot.net
Brian Moon wrote:
Is typing really the bottleneck for developers these days? I must suck
then. I spend most of my day thinking or waiting on version control,
testing and deploy applications, not typing.
+1. I don't think reducing key strokes should be a goal at all, the goal
should be readability above all.
Having read the other responses on this topic, I have to agree that
there's no need for any short syntax, so -1 on the short syntax from me.
(Forgot to send this to the list; sorry for the duplicate Brian!)
Ryan McCue
<http://ryanmccue.info/