Re: Multi-methods

Craig Chambers (chambers@klamath.cs.washington.edu)
Sun, 12 Jun 94 20:14:40 GMT

In article <2t5foi$69j@darum.uni-mannheim.de>, mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) writes:
|> Tim wrote:
|> > + Even in Cecil, which was designed from the ground up to support MMs,
|> > Chambers stresses repeatedly that a graphical programming environment
|> > is vital (his word) to keep the programmer's view of the world
|> > manageable.
|>
|> I think that need not be as horrible as in Cecil when one doesn't use
|> multi-methods for everything. (Btw, Common-Lisp programmers are using
|> multi-methods as well, and it may be well worth asking there. I'm not
|> so sure whether it's so difficult to come up with a reasonable scheme
|> for method placement etc. in the common cases.)

Well, it's not exactly horrible in Cecil. Today we're living in text files,
and while it's not ideal, it's still doable. Most of our methods are
singly-dispatched anyway; maybe 10-20% are multiply-dispatched. Certainly
the CLOS folks survive with text-based multi-methods.

|>
|> > + Even in Cecil, which has a great deal of static type info available at
|> > compile time, decent speed requires sophisticated profile-based
|> > feedback to the compiler, specifically aimed at speeding MM-style
|> > dispatch searches.
|>
|> This is again with a very different expectation about speed than any-
|> one using Python today might even dream of.

Actually, Cecil has a negligible amount of static *implementation*
information upon which to base its optimizations. In this respect it
is much like Smalltalk, CLOS, or Self, and this lack of static info is
what leads to sophisticated optimizations. Cecil does allow a lot of
static *interface* information to be included (i.e. type declarations),
but this interface information doesn't help out the compiler much.

None of the optimizations are "specifically aimed" at multi-methods;
rather, they are aimed at dynamic binding in general and we intend
them to apply just as well to singly-dispatched code. We are avoiding
optimizations that don't scale well to multiple dispatching, however.

|> Given the complexity of the issue, I'm mostly agreeing with Tim, that
|> we better shouldn't (yet) build multi-methods deeply into Python.

This is reasonable. Multi-methods are still a technology in development,
and reasonable people can choose to omit them until the issues surrounding
them are more well understood. Incidentally, one of the big areas of
research we're working on now is a module system that supports independent
development of libraries that incorporate multi-methods. More information
can be obtained on this and other Cecil projects either via anon. ftp from
cs.washington.edu:pub/chambers or via WWW from http://www.cs.washington.edu/
research/projects/cecil/www/cecil-home.html.

-- Craig Chambers