Re: [PHP-DEV] Implementation help needed: Currying RFC
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementation help needed: Currying RFC
Hi Johannes, Thank you very much for your detailed feedback. Am 07.06.11 12:40 schrieb Johannes Schlüter unter johan...@schlueters.de: [...] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Implementation help needed: Currying RFC
$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.
Re: [PHP-DEV] Implementation help needed: Currying RFC
Hi John,
thanks for your feedback.
Am 07.06.11 15:43 schrieb John Crenshaw unter johncrens...@priacta.com:
[...]
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementation help needed: Currying RFC
Martin Scotta On Tue, Jun 7, 2011 at 10:43 AM, John Crenshaw johncrens...@priacta.comwrote: $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.
RE: [PHP-DEV] Implementation help needed: Currying RFC
-Original Message-
From: Lars Strojny [mailto:l...@strojny.net]
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementation help needed: Currying RFC
Hi Martin, Am 07.06.11 17:09 schrieb Martin Scotta unter martinsco...@gmail.com: [...] 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
RE: [PHP-DEV] Implementation help needed: Currying RFC
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementation help needed: Currying RFC
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 l...@strojny.net: Hi Martin, Am 07.06.11 17:09 schrieb Martin Scotta unter martinsco...@gmail.com: [...] 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
