Lambda the Ultimate

The conditional syntax looks ugly to me. Interesting that he's adding another way to do things despite his philosophy of only-one-good-way-to-do-it.

From what I've read, Psycho will optimize based on generating several versions of a function specialised by type. What I was thinking was partial evaluation based on values.

I'm not sure what you are for? Psyco operates on Python bytecodes and translates/compiles code-blocks at runtime. For better reusibility it "widens" the concrete values using runtime type information. This is an effective strategy for not letting increase the number of code-block versions arbitrarily.



Psyco does not perform eager evaluations with "holes" like e.g. Maple does. This is likely the most intuitive application of PE. If one defines a Maple function

h := proc(x,y)
    sin(x/3)*cos(x*y)
end proc;

one can specialize it on a certain value and receive an other function as value.

> g:= h(x,2);
                              /1  \         
                     g := sin| - x | cos(2 x)
                              \3  /         
> eval(g,x=9);
                         sin(3) cos(18)

Here g can be considered as a specialized version of h. That's of course far more advanced than partial() that just stores the arguments and the function for later use.

From how you've described it, I am talking about what Maple does.

All that does is substitute the value 2 for y and the global name x for the local name x. Then it returns the last evaluated expression in the function, not another specialized function as you suggest. This is evident in the fact that in your example you can't do g(9) but must do eval(g, x=9). The fact that Maple has a built-in auto-simplifier sometimes makes it look like some PE is going on. But generally I think of PE as being far more advanced that what you can do in Maple.

At least they got the terminology right. In Maple and Groovy this function is called curry(). And I have to say that I do find it very useful in day-to-day Maple programming.

My version of partial application is a little easier on the eyes when using operators, I think:

>>> from partial import _
>>> addWorld = _ + " world!"
>>> addWorld("Hello,")

"Hello, world"

>>> mapcall(_.upper, ["list", "of", "strings"])

["LIST", "OF", "STRINGS"]

>>> 

Should have submitted a PEP, I guess!

The underscore has special meaning (albeit not used often) as 'result of previous evaluation', e.g.

>>> 2+2
4
>>> _
4
>>> 

That's what I would've done, too, though. It seems like a very intuitive leap from the existing syntax.

My experience with Dylan/Scheme, which also have a "curry" function (yeah, they get the name wrong), is that brevity is very important for partial application. Haskell and Ocaml get a big win from just leaving off the last argument, though at the expense of a lack of flexibility (those damn 'flip's get very annoying in Haskell). An underscore gets all their brevity points while still being intuitive and allowing one to partially apply arguments other than the leftmost.

'My experience with Dylan/Scheme, which also have a "curry" function (yeah, they get the name wrong)'

I'm not sure which Scheme has a "curry" function, but I like the SRFI for specialized parameters:

SRFI 26

I think you are probably right. Guido has said before that he wants to eliminate lambdas in a future version.

That's a real shame, unless it's replaced by a lightweight syntax for anonymous functions that matches the built-in control flow statements. The lambda ... syntax is pretty ugly in comparison to if, while, def etc.

I agree. If his complaint is with the word "lambda" then just give it a better syntax. The concept of lambda expressions is still a good concept. But regardless, it isn't that big of a loss, after all, it will still be possible to define closures, and that's really what makes lambdas so great in the first place, right?

It's easy to be sarcastic when you don't have a community of programmers relying on your work and nobody cares about the design decisions you make.

When people get excited over the mundane. Or rather, the mundane, done wrong.

Language evolution poses a different set of problems (back compatibility, community support for changes, cohesion etc.) That's not to say, of course, that all changes are of equal quality. Language evolution should be analyzed with the same care given to truly innovative features.

Both these aspects are discussed here often. It might be helpful to be explicit about what is interesting in the developments we cover. If someone claims that X is an innovative language feature, it is quite natural to object, if in fact it isn't new. If the interest stems from the way new features are added to an existing language, that's not a valid objection.