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
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
$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.
Martin Scotta
On Tue, Jun 7, 2011 at 10:43 AM, John Crenshaw johncrenshaw@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 objectThis 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.
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.