RE: [Python-Dev] Re: PEP 309, function currying
From: Peter Harris
Yes, that's currying alright, which PEP 309 does in no way describe. Hmm. OK, there is way too much imprecise thinking behind that PEP. Sorry.
Quick unscientific name poll. Who likes...
* curry()
* closure()
* partial()
* partial_apply()
* delayed()
* other ?
I like curry(). The others don't bring the right concept to mind for me. I apologise if this offends the purists, but *all* of the recent attempts to "clarify" the difference between partial application and currying have simply confused me. If curry() gets screams of outrage, someone suggested bind() to follow the Boost C++ library's usage. That's tolerable, although I find it too generic a word. Paul
Moore, Paul wrote:
If curry() gets screams of outrage, someone suggested bind() to follow the Boost C++ library's usage. That's tolerable, although I find it too generic a word.
I'm not really tracking all the details of this discussion, but thought I'd throw bind_args() into the ring as a possible name. I suspect bind() would have too many people looking for the nearest TCP/IP stack. . . Regards, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan@email.com | Mobile: +61 409 573 268
On Feb 24, 2004, at 5:18 AM, Nick Coghlan wrote:
Moore, Paul wrote:
If curry() gets screams of outrage, someone suggested bind() to follow the Boost C++ library's usage. That's tolerable, although I find it too generic a word.
I suspect bind() would have too many people looking for the nearest TCP/IP stack. . .
In a "functional" module? Jeremy
Paul Moore wrote:
I like curry(). The others don't bring the right concept to mind for me. I apologise if this offends the purists, but *all* of the recent attempts to "clarify" the difference between partial application and currying have simply confused me.
Partial application is specifying some of the arguments of a function, so you get a new function that takes fewer arguments. Currying is making a function take one argument at a time, doing partial application as it goes. Highbrow but enlightening example: Suppose F is a function that takes a programming language spec and a program in that language, and executes the program. (You could call it a "generic interpreter".) Then - Partial application turns F into a specialized interpreter, such as a Python interpreter. The partially applied function takes fewer parameters, because some have been fixed. - Currying turns F into an interpreter generator. You feed it a language spec and it spits out an interpreter. The curried function takes the same number of parameters, but you give it them in a different way. "Curry plus call equals partial-apply."
If curry() gets screams of outrage, someone suggested bind() to follow the Boost C++ library's usage. That's tolerable, although I find it too generic a word.
I think I like that better than the other proposals currently on the table. * By the way, "purists" are more likely to be offended by being caricatured ("purists", "screams of outrage") than by the fact that someone has difficulty understanding what they say. But it's no big deal. -- g
I like curry(). The others don't bring the right concept to mind for me. I apologise if this offends the purists, but *all* of the recent attempts to "clarify" the difference between partial application and currying have simply confused me.
Let me try an example, partly to be sure I understand it. Suppose have a function f with five arguments. Then I think you are proposing a function, which I shall call X for the moment, with the property that evaluating g = X(f, a, b) z = g(c, d, e) has the same effect as z = f(a, b, c, d, e) At least, that's how the code in the PEP seems to behave. If so, that's not currying. Currying would work like this: g = curry(f) # Note -- no other arguments g1 = g(a) g2 = g1(b) g3 = g2(c) g4 = g3(d) z = g4(e) with z having the same value as f(a, b, c, d, e) afterward. Note that curry takes only one argument, namely f. Instead of taking an argument of f directly, it returns a function that will accept f's first argument. It is that extra level of indirection that distinguishes currying from partial application.
"Moore, Paul"
From: Peter Harris
Yes, that's currying alright, which PEP 309 does in no way describe. Hmm. OK, there is way too much imprecise thinking behind that PEP. Sorry.
Quick unscientific name poll. Who likes...
* curry()
* closure()
* partial()
* partial_apply()
* delayed()
* other ?
I like curry(). The others don't bring the right concept to mind for me. I apologise if this offends the purists, but *all* of the recent attempts to "clarify" the difference between partial application and currying have simply confused me.
If curry() gets screams of outrage, someone suggested bind() to follow the Boost C++ library's usage. That's tolerable, although I find it too generic a word.
Perl 6 plans to use f.assuming() for this. Search for "curry" in http://dev.perl.org/perl6/apocalypse/A06.html. The perl6 folks also use the term "curry" to mean "partial application". Regards, Gisle Aas, ActiveState
participants (6)
-
Andrew Koenig -
Gareth McCaughan -
Gisle Aas -
Jeremy Fincher -
Moore, Paul -
Nick Coghlan