Adventures in Currying

[Michael Hudson]

nickm at mit.edu (Nick Mathewson) writes:

> I've noticed that about 2/3 of the times I use lambda in Python, I'm
> really just asking for curried functions.[*] With this in mind, I
> started writing up currying operators of various degrees of
> complexity.  I give them below, in their approximate evolutionary
> order.  They are all classes designed to turn python functions into
> curried functions.
> 
> They're all tested with 1.5.2, but rely on undocumented attributes of
> function and code objects.  Therefore, they may break on 1.6, and are
> certain to break in JPython.

Are you aware of my bytecodehacks package?  One of the modules in it
is "xapply", which basically curries functions.  You can see it here:

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/bytecodehacks/bytecodehacks/xapply.py?rev=1.9&content-type=text/x-cvsweb-markup&cvsroot=bytecodehacks

and read about it here:

http://bytecodehacks.sourceforge.net/bch-docs/bch/module-bytecodehacks.xapply.html

(sorry for the long lines!)

If you thought your code was hairy, you haven't seen
xapply._xapply_munge - which is certainly the hairiest piece of Python
code I've ever written, and quite possibly ever read.  It seems this
hairiness is inherent in the problem.

The key difference with my module is that 

def f(x,y):
    return x+y

type(xapply.xapply(f))

gives "function" - so calling it is as fast as calling any other
function.

I think it should work with 1.6 (can't think why not anyway); it
hasn't a hope with JPython.

i-sense-another-of-my-kind-ly y'rs
M.

-- 
  If i don't understand lisp,  it would be wise to not bray about
  how lisp is stupid or otherwise criticize, because my stupidity 
  would be archived and open for all in the know to see.
                                               -- Xah, comp.lang.lisp