Re: Multiple polymorphism / multi-methods

[vme131!lsiserv1!jecel@uunet.UU.NET (Jecel Mattos Assumpcao Jr)]

>I love the idea of putting lookup within the language.
>Perhaps the VM shouldnt implement any kind of inheritance at all?

I would sure like to have method lookup within the language, but how would
it work? If you have a system-wide findMethod:for:args: method which you can
change then the whole system must work one way or another :-(. If an object
could have its own findMethod it would be better, but it could not inherit it
from another object unless you accept the default inheritance method for
getting to findMethod ( then there would be two inheritance graphs for each
object: the normal one for findMethod and a custom one for all other methods ).

>I like your mental model of multiple polymorphism: sending a message
>to all the arguments.  Also, multi-methods being "in" all their
>arguments rather than just their receiver is a nice use of sharing.

Does "self" still have any meaning in this case?

>... it would seem to be desirable to have some
>indication where multiple polymorphism is occurring.  This could be
>the programming environment's job, rather than the user's job.  I am
>still undecided as to whether or not to mark polymorphic arguments.

In a single inheritance, class-based language you could just say the
arguments are "anObject" to get the receiver-only polymorphic behavior. In
a multiple polymorphic SELF things get harder.

>The most common use of multiple polymorphism would be for arithmetic
>operators such as '+'.  There would be separate methods for 'integer +
>integer' and 'integer + float', so no explicit type checking or double
>dispatching would be needed.  Another example of where multiple
>polymorphism would be useful is for the displayOn: method.  Let's say
>there are four types of forms, regular ones (1 bit plane), opaque ones
>(2 bit planes: one is a mask), color ones (many bit planes), and
>opaque color ones (many bit planes: one is a mask).  We would like to
>be able to display any kind of form on any other kind of form using
>any of several rules/modes (copy, reverse, etc).  This could be
>implemented nicely as a multi-method:
>
>   form             displayOn: form            At: point Rule: copy
>   opaqueForm                  opaqueForm                      reverse
>   colorForm                   colorForm                       drawBlack
>   opaqueColorForm             opaqueColorForm                 eraseWhite
>
>There are 4 x 4 x 4 = 64 combinations, most of which would be valid
>methods.  Can you imagine implementing this using triple dispatching?
>Ugh!

Another classical example: circle     drawOn:  screen
                           rectangle           printer
                           polygon             plotter

The problem with multiple polymorphism is that you still have to write all
those methods; you just get better performance and avoid having to invent
dozens of method names ( a very important gain ).

Although I've been burned by Smalltalk's coersion mechanism for arithmetic,
I like how inheritance takes care of most of the details. It might be very,
very slow in the case of displayOn:At:Rule:, but you might get by with just
16 methods or less.

A classic solution for the drawOn: method is to choose a simple primitive
like "line:". Circle, rectangle and polygon would only call line: without
worrying about the output device. Screen, printer and plotter need only
implement the line: method. A new geometric figure or a new output device
mean only a single method must be written.

I like multiple polymorphism, but worry about the number of methods that
must be written or changed as the system evolves.

Re: Self and Scheme

>  This is one thing I was discussing with a Smalltalk hacker a couple
>of days ago. One of the really beautifull things about Lisp and
>Lisp-like things (assembly language is the only non-Lisp derived
>language that also has this property) is that program is data and data
>is program. 
 
Actually machine language ( and not in all OSs or machines ), not assembly
has this property. Back in 1984 I designed ( but never tested ) a Smalltalk
that compiled to objects: message prototype trees. Although most objects
were not code, all code were objects. Bytecode objects can also be built
at run time in theory, but somehow it doesn't feel the same.

Jecel