gmane.comp.lang.dylan.gwydion.devel

Gabor Greif | 4 Jan 13:18

Chinese Dispatch for Multimethods

Hi Bjarne,

I have just noticed your paper "Open Multi-Methods for C++"
<http://www.research.att.com/~bs/multimethods.pdf>.

Therein you hint a possible implementation variant using the
chinese remainder theorem. Incidentally, I had this idea
more than 10 years ago and finally came around to put it
in words for the 2002 Dylan Hackers' Conference in Berlin.

There I held a short talk. Thereafter I wrote up
something that resembles a paper and checked it in the
Dylan repository. Here it is, you might be interested
in skimming it and comparing it with your approach:

<http://www.opendylan.org/cgi-bin/viewcvs.cgi/trunk/www/papers/ChineseDispatch.lout?rev=8014&view=markup>

Back then I was an active developer of the d2c Dylan compiler,
but only as a hobbyist. The paper has never been finished,
thus never published. It is in a very rough state (figures
that are taken from example documents, etc.), please excuse
me of sending you such a rubbish...

I can also make it to a pdf if you are interested.

All in all I am very happy that the multi-dispatch idea
is being actively pursued again, as I am thinking that
it solves one of the ugliest problems in programming. We
(the Dylan community) use multi-methods excessively
and it is a very natural way of associating behaviour

(Continue reading)

headers

Bruce Hoult | 4 Jan 14:04

Re: Chinese Dispatch for Multimethods

On Jan 5, 2008 1:20 AM, Gabor Greif <gabor <at> mac.com> wrote:
> We (the Dylan community) use multi-methods excessively

Hopefully Gabor means "extensively"!!

I pointed #dylan (freenode IRC) at this paper a few hours ago.  Most
interesting and it would certainly make my professional life more
pleasant if this made it into C++ in the not too distant future.

Putting on my language lawyer hat (last seen in c.plus.plus on BIX in
the late 80's/early 90's), I have a couple of questions:

1) is it *required* for overriders to use the virtual keyword on each
argument, or can it be implied as it can for regular virtual
functions?

You wrote:
>A ﬁrst known consideration of repeated and virtual inheritance for
multi-methods.

Dylan has *only* virtual inheritance, though it's implemented a bit
differently.  Fields from base classes are included only once in an
object no matter how many times that base class is mentioned in the
inheritance graph.  There is no need to offset the "this" pointer or
to have internal pointers to the one instance of a base class's fields
because field accessors are themselves virtual functions.

Of course when you're somewhere where the class of an object is known
exactly then you can use a fixed offset to access the field.

(Continue reading)

headers

Chris Page | 4 Jan 21:33

Re: Chinese Dispatch for Multimethods

On Jan 4, 2008, at 05:04 AM, Bruce Hoult wrote:

> Dylan has *only* virtual inheritance, though it's implemented a bit
> differently.  Fields from base classes are included only once in an
> object no matter how many times that base class is mentioned in the
> inheritance graph.  There is no need to offset the "this" pointer or
> to have internal pointers to the one instance of a base class's fields
> because field accessors are themselves virtual functions.

I should probably add: If you declare a class "primary" then its slots  
are accessible more efficiently. Only one chain of "primary"  
superclasses can be inherited in a multiple inheritance situation.

I usually describe it as the opposite of C++: You get virtual  
inheritance by default and explicitly declare primary ("non-virtual")  
inheritance. (Of course, that's a loose analogy.)

 From the DRM:

   <http://www.opendylan.org/books/drm/Declaring_Characteristics_of_Classes#IX-1111 
 >

   "An explicitly defined class may be declared to be either primary  
or free. The default is free. Each primary superclass of a class must  
be either a subclass or a superclass of all the other primary  
superclasses of the class. (This essentially restricts primary classes  
to forming a single inheritance chain.) Slots defined in a primary  
class may be accessed more efficiently than slots defined in a free  
class."

(Continue reading)