PEP309 - built-in curry class (revisions)

[Carl Banks]

Peter Harris wrote:
> Before I upload another (less drastically ambitious) version of
> PEP 309, I want to thrash out a few things.
> 
> Several people have said curry() belongs in the standard library
> rather than as a built-in. If so, what should the module name be,
> and what sort of other things might the module contain?
> 
> The PEP is for a built-in of course, but I would be delighted
> with inclusion in the standard library too, so I would like to
> make a constructive proposal for it.
> 
> How about the following?
> 
>    Module to be called "functional" (it can be a home for
>    operations on higher-order functions in general.)

Good idea.


>    functional.curry() as a nested function.
> 
>    functional.Curry as a class, so those who want the
>        introspection and sub-classing can have it.

I assume this module would be written in C?  Then there's not much
point in having a separate curry as a nested function.  The nested
function curry's main advantage over the Python class form is that
it's easier to write, more straightforward (to me) to read, and
faster.  The first two advantages won't matter in a standard module,
and a class written in C will be faster than the closure.

As for the contents of the module, even if a general curry that can
pick and choose its arguments isn't a good idea, there should at least
be a right curry along with a left curry, so you can do things like
this (to return first item of a list):

    curryright(operator.getitem,0)

You cannot do this simple thing with just a left curry.


Another interesting thing, in my mind, to have is structure pattern
matching.  This is quite a larger endeavor than currying.  And it
probably should be designed to avoid the "get-and-set" indentation
problems that plague regular expression matching.


A new list-type that can grow on both ends would help functional
programming a lot.


-- 
CARL BANKS