Lambda the Ultimate

I will have to look more closely at the abstract interfaces work.

I hope that the future version supporting DbC (see roadmap) will make use the recent work on sound contracts from Rice.

There's a nice friendly web-site with most of the information that curious people will want to know. He still doesn't have a FAQ but he's identified the areas where this language would be useful, identified why people would want to use it, detailed the special features, provided an example of the code and (best of all) piggy-backed upon the feature-set of an existing popular language. [And it has an Emacs mode so there's no excuse for not trying it out.]

This is exactly the kind fo thing that helped C++ and Java get widespread. That and the hype merchants.

There does seem to be a proliferation of object-functional programming languages at the moment. The object-functional name has precedence I think and might be a better choice than a FOOPL category. See http://lambda-the-ultimate.org/classic/messagx989 and Thomas Kuehne's PhD thesis (http://www-agce.informatik.uni-kl.de/~kuehne/fps and http://c2.com/cgi/wiki?FunctionalPatternSystemForObjectOrientedDesign).

The object-functional merger is one of my favourite features of Python and it seems to offer concrete benefits that are accessible to people who have no interest in the lambda calculus.

So apart from Python, Ruby and Nice what other object-functional programming languages are there? I'm not sure that Perl counts.

So apart from Python, Ruby and Nice what other object-functional programming languages are there?

Maybe it would be more productive to consider only languages that either support well defined functional programming constructs (first class continuations...) or that provide an OOP framework based on immutable objects?

In response to Ehud: could you give pointers to the recent work on DBC / sound contracts that you mention? As for abstract interfaces, I have a reseach article that has just been accepted for the Types in programming workshop. It will be available in a few weeks on the academic research page on the Nice website.

In Nice, a multi-method is made of two complementary parts: the method declaration, and multiple implementations, possibly scattered in different files and packages. I think this is much cleaner that classical OO languages, where the two concepts are mixed, which create many problems. First, it raises questions like "can the new method change the arguments/return type, the exceptions thrown, the contract (our main issue here). Also, it is not possible, looking at a class definition, to know wether a method overrides a method in the parent or not (unless you add an 'override' keyword like in Object Pascal, which essentially amounts to reestablishing the distinction, but poorly (you still have to mention the types).

I think that the method declaration is the place where the specification (in the general sense) is established: there goes the type, the pre- and post-conditions, the method documentation (what does this method do). Then each implementation has the task to implement this contract in one case (dispatching on some arguments' classes). I think this nicely fits with the separation of specification and implementation, that is otherwise somewhat blurred.

Note that you can have precise specifications, like covariant return types, by using constrained polymorphic types in the method declaration. I would be interested to hear challenges about extending the contract depending on the implementation. Does it go beyond class invariant and assertions in the implementation code?

class Collection<T> { void add(T elem) POST: this.size() = old.size() + 1; }

The ouside user knows this post-condition and can rely on it.

Now suppose I implement Collection as a linked list, and decide to add at the front. Then the fact that 'this.get(0) == elem' is true at the end of the method, but since it is not relevant to the user, it should be be 'assert'ed at the end of the code, rather that put in a postcondition. If I later change my implementation decisions, I will not need to change the spec (post-condition), which is good.

So my (tentative) claim is that the contract of a method should be declared only once. Implementations (or overriden versions) must of course follow the same contract, but do not need to refine it, since they are just different implementations of the same operation. Does that sound reasonable?