FAQ
Hi everybody,

if you know how to do some weird things to PHP¹s parser and like
functional¹ish elements in PHP, please read further.

I¹ve finally found some time to put together a first draft of an RFC for
currying (https://wiki.php.net/rfc/currying). This is basically meant as a
starting point to find a clean and concise syntax for PHP. So, if you
kinda like what you¹ve read or you think it¹s crazy or anything in
between, drop me a message.

With regards,
Lars

Search Discussions

  • Johannes Schlüter at Jun 7, 2011 at 10:40 am

    On Mon, 2011-06-06 at 01:28 +0200, Lars Strojny wrote:
    I¹ve finally found some time to put together a first draft of an RFC for
    currying (https://wiki.php.net/rfc/currying). This is basically meant as a
    starting point to find a clean and concise syntax for PHP. So, if you
    kinda like what you¹ve read or you think it¹s crazy or anything in
    between, drop me a message.
    I wonder how your proposal would work with a variable number of
    arguments.

    Taking a piece out of your RFC:
    $apos = curry strpos(..., 'a'));
    Would the parameter always be appended? So what would happen here:

    $apos(); // runtime error wrong param count?
    $apos("bar"); // fine
    $apos("bar", "foo"); // 'a' casted to long, used as offset?
    $apos("bar", "foo", 0); // run-time error wrong param count?

    I feel that this won't fit easily in the language, while the feature
    itself can be nice with all these callback things. I also don't know if
    it can be implemented in an efficient way. A simple way to implement is
    to create a closure. (which has performance impacts and misleading error
    messages in the cases shown above)

    I also think that

    Keyword curry should have an alias schoenfinkel

    should not be the case. It is nice to remember some people and such but
    I think this alias is just one more thing to know when reading code but
    serves no real purpose. I know the concept mostly as currying, Scala for
    instance seems to always reference it as currying.

    johannes
  • Lars Strojny at Jun 7, 2011 at 11:54 am
    Hi Johannes,

    Thank you very much for your detailed feedback.

    Am 07.06.11 12:40 schrieb "Johannes Schlüter" unter
    [...]
    I wonder how your proposal would work with a variable number of
    arguments.

    Taking a piece out of your RFC:
    $apos = curry strpos(..., 'a'));
    Would the parameter always be appended? So what would happen here:

    $apos(); // runtime error wrong param count?
    $apos("bar"); // fine
    $apos("bar", "foo"); // 'a' casted to long, used as offset?
    $apos("bar", "foo", 0); // run-time error wrong param count?
    Clarified this specifically in the new error handling paragraph. It should
    throw a warning/notice in cases 3 and 4, stating that the parameter is not
    used.
    I feel that this won't fit easily in the language, while the feature
    itself can be nice with all these callback things. I also don't know if
    it can be implemented in an efficient way. A simple way to implement is
    to create a closure. (which has performance impacts and misleading error
    messages in the cases shown above)
    Explained more detailed in the RFC, how I would try implementing it
    (indeed with closures or a specialization of them, look at the new
    paragraph „Implementation details").
    I also think that

    Keyword curry should have an alias schoenfinkel

    should not be the case. It is nice to remember some people and such but
    I think this alias is just one more thing to know when reading code but
    serves no real purpose. I know the concept mostly as currying, Scala for
    instance seems to always reference it as currying.
    As I set on #pecl.php, I will not fight for this alias :). So removed in
    the RFC.

    With regards,
    Lars
  • John Crenshaw at Jun 7, 2011 at 1:44 pm

    $apos = curry strpos(..., 'a'));
    $apos(); // runtime error wrong param count?
    $apos("bar"); // fine
    $apos("bar", "foo"); // 'a' casted to long, used as offset?
    $apos("bar", "foo", 0); // run-time error wrong param count?
    I understand where this can be useful sometimes, but I disagree that this should be added as a language feature. It is still possible to implement this (parameter positioning in your curried function) using a function that returns a closure similar to the curry_left example in the RFC. One possible method (inspired by the C++ system for doing the same thing) would be:

    $apos = curry( 'strpos', _1(), 'a' ); // _1() returns a placeholder positioning object

    This isn't quite as nice as the proposed T_FILL, but on the other hand, it is more powerful (parameters could change order) and isn't nearly as confusing as the RFC syntax (which looks like perhaps strpos is being called in some strange way).

    Of course, there is also always the regular old closure, which is far more explicit and leaves no confusion about exactly what is being returned.

    No offense to anyone who loves currying, but I don't see why this should be implemented. There are plenty of good options available for achieving identical or better results without modifying the language.

    John Crenshaw
    Priacta, Inc.
  • Lars Strojny at Jun 7, 2011 at 3:08 pm
    Hi John,

    thanks for your feedback.

    Am 07.06.11 15:43 schrieb "John Crenshaw" unter [...]
    I understand where this can be useful sometimes, but I disagree that this
    should be added as a language feature. It is still possible to implement
    this (parameter positioning in your curried function) using a function
    that returns a closure similar to the curry_left example in the RFC. One
    possible method (inspired by the C++ system for doing the same thing)
    would be:

    $apos = curry( 'strpos', _1(), 'a' ); // _1() returns a placeholder
    positioning object
    Interesting idea to use placeholder argument as it is implementable in
    user space (or as a PECL extension or a bundled one) without touching the
    parser. Maybe an arg()-Function which returns a placeholder object would
    be the way to go. Something like this maybe:

    $apos = curry('strposŒ, arg(1), 'aŒ);
    This isn't quite as nice as the proposed T_FILL, but on the other hand,
    it is more powerful (parameters could change order) and isn't nearly as
    confusing as the RFC syntax (which looks like perhaps strpos is being
    called in some strange way).
    Could you elaborate on how parameters could change order?
    Of course, there is also always the regular old closure, which is far
    more explicit and leaves no confusion about exactly what is being
    returned.
    That¹s true. The main motivation for this proposal is brevity and less
    boilerplate code for callbacks.
    No offense to anyone who loves currying, but I don't see why this should
    be implemented. There are plenty of good options available for achieving
    identical or better results without modifying the language.
    Thanks again for your opinion and the idea of having an argument
    placeholder.

    With regards,
    Lars
  • John Crenshaw at Jun 7, 2011 at 4:03 pm
    -----Original Message-----
    From: Lars Strojny
    I understand where this can be useful sometimes, but I disagree that this
    should be added as a language feature. It is still possible to implement
    this (parameter positioning in your curried function) using a function
    that returns a closure similar to the curry_left example in the RFC. One
    possible method (inspired by the C++ system for doing the same thing)
    would be:

    $apos = curry( 'strpos', _1(), 'a' ); // _1() returns a placeholder
    positioning object
    Interesting idea to use placeholder argument as it is implementable in
    user space (or as a PECL extension or a bundled one) without touching the
    parser. Maybe an arg()-Function which returns a placeholder object would
    be the way to go. Something like this maybe:

    $apos = curry('strposŒ, arg(1), 'aŒ);
    That would work too. The general idea for this type of implementation isn't mine. This is how C++ systems implement this, which is where the idea comes from. (See boost::bind)

    I like your arg(n) syntax better, but worry about namespace collisions (but again, that's less of an issue when implemented in user code, rather than at the language level).
    This isn't quite as nice as the proposed T_FILL, but on the other hand,
    it is more powerful (parameters could change order) and isn't nearly as
    confusing as the RFC syntax (which looks like perhaps strpos is being
    called in some strange way).
    Could you elaborate on how parameters could change order?
    Yeah. Consider this:

    $today_cookie = curry('setcookie', arg(1), arg(2), arg(4), 60*60*24, arg(3));

    Originally, the order of parameters in setcookie is ($name, $value, $expire, $path, $domain, ...). this changes the order to ($name, $value, $domain, $path) (which is common for setcookie wrappers, because it is often a more useful order).

    In any case, you can see how this type of implementation can be very flexible and tailored to specific application needs in a way that a language level implementation can't (for fear of bloat).

    John Crenshaw
    Priacta, Inc.
  • Martin Scotta at Jun 7, 2011 at 3:09 pm
    Martin Scotta

    On Tue, Jun 7, 2011 at 10:43 AM, John Crenshaw wrote:

    $apos = curry strpos(..., 'a'));
    $apos(); // runtime error wrong param count?
    $apos("bar"); // fine
    $apos("bar", "foo"); // 'a' casted to long, used as offset?
    $apos("bar", "foo", 0); // run-time error wrong param count?
    I understand where this can be useful sometimes, but I disagree that this
    should be added as a language feature. It is still possible to implement
    this (parameter positioning in your curried function) using a function that
    returns a closure similar to the curry_left example in the RFC. One possible
    method (inspired by the C++ system for doing the same thing) would be:

    $apos = curry( 'strpos', _1(), 'a' ); // _1() returns a placeholder
    positioning object

    This isn't quite as nice as the proposed T_FILL, but on the other hand, it
    is more powerful (parameters could change order) and isn't nearly as
    confusing as the RFC syntax (which looks like perhaps strpos is being called
    in some strange way).

    Of course, there is also always the regular old closure, which is far more
    explicit and leaves no confusion about exactly what is being returned.

    No offense to anyone who loves currying, but I don't see why this should be
    implemented. There are plenty of good options available for achieving
    identical or better results without modifying the language.
    Hey Jhon,

    What about writing your curry idea in plain PHP, as a proof of concept.
    Then you can show examples live and others can toy with it.

    I'm pretty sure most php developers are not used to curry -- or at least
    those who don't have functional programming skills


    John Crenshaw
    Priacta, Inc.
  • Lars Strojny at Jun 7, 2011 at 4:14 pm
    Hi Martin,

    Am 07.06.11 17:09 schrieb "Martin Scotta" unter [...]
    Hey Jhon,

    What about writing your curry idea in plain PHP, as a proof of concept.
    Then you can show examples live and others can toy with it.
    Yep, working on it.

    With regards,
    Lars
  • Lars Strojny at Jun 7, 2011 at 5:09 pm
    So, here we go, simple prototype of what John suggested:

    - Test Case:
    https://github.com/lstrojny/functional-php/blob/playground/tests/Functional
    /CurryTest.php
    - Implementation:
    https://github.com/lstrojny/functional-php/blob/playground/src/Functional/C
    urry.php

    With regards,
    Lars

    Am 07.06.11 18:14 schrieb "Lars Strojny" unter <lars@strojny.net>:
    Hi Martin,

    Am 07.06.11 17:09 schrieb "Martin Scotta" unter [...]
    Hey Jhon,

    What about writing your curry idea in plain PHP, as a proof of concept.
    Then you can show examples live and others can toy with it.
    Yep, working on it.

    With regards,
    Lars



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • John Crenshaw at Jun 7, 2011 at 4:15 pm

    Hey John,

    What about writing your curry idea in plain PHP, as a proof of concept.
    Then you can show examples live and others can toy with it.

    I'm pretty sure most php developers are not used to curry -- or at least those who don't have functional programming skills
    I'll consider this. The basic theory is pretty simple. You need an object that identifies a parameter position, and a short syntax for referencing that object. I think anyone familiar with currying should be able to get the basic idea from that, so I don't think this stops the discussion from moving forward, but if a userland implementation is needed to demonstrate why a parser level implementation isn't, I can throw together something basic, or at least some pseudo-code.

    John Crenshaw
    Priacta, Inc.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJun 5, '11 at 11:29p
activeJun 7, '11 at 5:09p
posts10
users4
websitephp.net

People

Translate

site design / logo © 2022 Grokbase