FAQ
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?



1. 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/



2. 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.



3. 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;



4. 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.



5. 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

Search Discussions

  • Rasmus Lerdorf at Aug 4, 2011 at 7:23 am

    On 08/04/2011 12:08 AM, Lazare Inepologlou wrote:
    $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
  • Dukeofgaming at Aug 4, 2011 at 7:31 am
    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
    On Thu, Aug 4, 2011 at 2:23 AM, Rasmus Lerdorf wrote:
    On 08/04/2011 12:08 AM, Lazare Inepologlou wrote:
    $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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stas Malyshev at Aug 4, 2011 at 7:52 am
    Hi!
    On 8/4/11 12:31 AM, dukeofgaming wrote:
    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
  • Frédéric Hardy at Aug 4, 2011 at 8:50 am
    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
    ========================================================================
  • Lazare Inepologlou at Aug 4, 2011 at 8:59 am
    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#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
    ========================================================================
  • Lazare Inepologlou at Aug 4, 2011 at 8:53 am
    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>
    On 08/04/2011 12:08 AM, Lazare Inepologlou wrote:
    $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
  • Ryan McCue at Aug 4, 2011 at 11:18 am

    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.
  • Johannes Schlüter at Aug 4, 2011 at 11:39 am

    On Thu, 2011-08-04 at 21:18 +1000, Ryan McCue wrote:
    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
  • Lazare Inepologlou at Aug 4, 2011 at 12:40 pm

    ... ( $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:
    1. A lambda expression can be part of other expressions, like arrays.
    Therefore, we cannot reuse =>, or ->.
    2. Multiple lambda expressions can be chained. The operator must have
    very low precedence and it be right associative.
    3. 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>:
    On Thu, 2011-08-04 at 21:18 +1000, Ryan McCue wrote:
    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

  • Antony Dovgal at Aug 4, 2011 at 12:49 pm

    On 08/04/2011 04:39 PM, Lazare Inepologlou wrote:
    ... ( $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
  • Victor Bolshov at Aug 4, 2011 at 12:57 pm
    +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>
    On 08/04/2011 04:39 PM, Lazare Inepologlou wrote:

    ... ( $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


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derick Rethans at Aug 4, 2011 at 1:04 pm

    On Thu, 4 Aug 2011, Victor Bolshov wrote:

    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
  • Antony Dovgal at Aug 4, 2011 at 1:12 pm

    On 08/04/2011 05:04 PM, Derick Rethans wrote:
    On Thu, 4 Aug 2011, Victor Bolshov wrote:

    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
  • Gwynne Raskind at Aug 4, 2011 at 6:47 pm

    On Thu, Aug 4, 2011 at 09:12, Antony Dovgal wrote:
    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.
  • Dukeofgaming at Aug 4, 2011 at 6:54 pm

    On Thu, Aug 4, 2011 at 1:47 PM, Gwynne Raskind wrote:
    On Thu, Aug 4, 2011 at 09:12, Antony Dovgal wrote:
    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.
  • Paul Dragoonis at Aug 4, 2011 at 7:04 pm

    On Thu, Aug 4, 2011 at 7:54 PM, dukeofgaming wrote:
    On Thu, Aug 4, 2011 at 1:47 PM, Gwynne Raskind wrote:
    On Thu, Aug 4, 2011 at 09:12, Antony Dovgal wrote:
    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.
  • Ivan Enderlin @ Hoa at Aug 4, 2011 at 9:03 am
    Hi all :-),
    On 04/08/11 09:23, Rasmus Lerdorf wrote:
    On 08/04/2011 12:08 AM, Lazare Inepologlou wrote:
    $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/
  • Arvids Godjuks at Aug 4, 2011 at 12:19 pm

    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 :)
  • Arvids Godjuks at Aug 4, 2011 at 12:27 pm
    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
  • Brian Moon at Aug 4, 2011 at 3:58 pm
    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
  • Ryan McCue at Aug 5, 2011 at 3:12 pm

    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!)
  • Jezz Goodwin at Aug 4, 2011 at 7:52 pm
    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
  • Matthew Weier O'Phinney at Aug 4, 2011 at 8:00 pm

    On 2011-08-04, Jezz Goodwin 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 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
  • Jezz Goodwin at Aug 4, 2011 at 8:16 pm

    On 04/08/2011 21:00, Matthew Weier O'Phinney wrote:
    On 2011-08-04, Jezz Goodwinwrote:
    --------------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!
  • Johannes Schlüter at Aug 4, 2011 at 8:53 pm

    On Thu, 2011-08-04 at 21:17 +0100, Jezz Goodwin wrote:
    :($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
  • Jezz Goodwin at Aug 4, 2011 at 9:01 pm
    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.


    On 04/08/2011 21:53, Johannes Schlüter wrote:
    On Thu, 2011-08-04 at 21:17 +0100, Jezz Goodwin wrote:
    :($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
  • Stas Malyshev at Aug 4, 2011 at 9:54 pm
    Hi!
    On 8/4/11 2:02 PM, Jezz Goodwin wrote:
    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
  • Jérémy Poulain at Aug 4, 2011 at 8:42 pm
    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>
    On 2011-08-04, Jezz Goodwin 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 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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Jezz Goodwin at Aug 4, 2011 at 8:53 pm

    On 04/08/2011 21:42, Jérémy Poulain wrote:
    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...
    Agreed about multiple lines. I don't think that there should be a way to
    use an explicit return if you want a multiple line function.

    In the examples I gave I would do something like this to return $x+1 :

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

    If you wanted to use multiple lines, I think you should be forced in to
    braces {} and do it the old fashioned way.

    :($x){
    $x = $x + 1;
    return $x;
    }



    Jérémy Poulain

    2011/8/4 Matthew Weier O'Phinney<weierophinney@php.net>
    On 2011-08-04, Jezz Goodwinwrote:
    --------------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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Sebastian Krebs at Aug 4, 2011 at 8:21 pm
    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;
    }


    On 04.08.2011 21:52, Jezz Goodwin wrote:
    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



  • Jezz Goodwin at Aug 4, 2011 at 8:34 pm
    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() );


    On 04/08/2011 21:20, Sebastian Krebs wrote:
    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;
    }

Related Discussions

People

Translate

site design / logo © 2022 Grokbase