Re: Best multimethods/multiple dispatch implementations?

=?ISO-8859-1?Q?Christoffer_Lern=F6?= <lerno@dragonascendant.com>
Mon, 8 Sep 2008 10:53:21 -0700 (PDT)

          From comp.compilers

Related articles
Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-05)
Re: Best multimethods/multiple dispatch implementations? FSet.SLB@gmail.com (Scott Burson) (2008-09-05)
Re: Best multimethods/multiple dispatch implementations? mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2008-09-06)
Re: Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-08)
Re: Best multimethods/multiple dispatch implementations? sh006d3592@blueyonder.co.uk (Steve Horne) (2008-09-09)
Re: Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-15)
Re: Best multimethods/multiple dispatch implementations? gneuner2@comcast.net (George Neuner) (2008-09-15)
Re: Best multimethods/multiple dispatch implementations? sh006d3592@blueyonder.co.uk (Stephen Horne) (2008-09-17)
Re: Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-18)
Re: Best multimethods/multiple dispatch implementations? bettini@dsi.unifi.it (Lorenzo Bettini) (2008-09-18)
[12 later articles]
| List of all articles for this month |

From: =?ISO-8859-1?Q?Christoffer_Lern=F6?= <lerno@dragonascendant.com>
Newsgroups: comp.compilers
Date: Mon, 8 Sep 2008 10:53:21 -0700 (PDT)
Organization: Compilers Central
References: 08-09-026 08-09-030
Keywords: OOP, code
Posted-Date: 10 Sep 2008 06:43:10 EDT

On Sep 6, 10:51 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Theoretically multiple dispatch can be as efficient as indexing a
> multidimensional array. The dispatch table of a method is such an array
> indexed by the type tags of the arguments (and possibly of the result). To
> make these indexes dense, one would likely map each tag to the
> corresponding index.


I looked at one "Eo,cient Compression of Generic Function Dispatch
Tables" by Eric Kidd: http://www.cs.dartmouth.edu/reports/TR2001-404.pdf
which, if I understand, is applicable to any language with C3
linearization of classes since since C3 linearized classes satisfy the
monotonicity requirement.


It looks like it should be very fast, even when using the compression
schemes in Kidd's paper.


In fact I may be overlooking something, but it almost looks like it is
faster than normal Objective-C dispatch.


> > 2. Is it feasible to base an OO-language on multiple dispatch (I was
> > thinking left-to-right to resolve ambiguous calls like CLOS) so that
> > someObject.someMethod() becomes syntactic sugar for the function
> > someMethod(someObject).
>
> I don't see any ambiguity in multiple dispatch, Talking about feasibility,
> single dispatch is clearly infeasible for multi-methods. Also infeasible is
> to consider methods as members of a type/object. (The sugar X.Y(Z) |=
> Y(X,Z) is OK to me.)


I don't quite follow you, what do you mean by X.Y(Z) |= Y(X,Z)?


> > This is how a lot of dynamically typed OO
> > already are built, but without single dispatch on the remaining
> > arguments, which allows for some simplifications (and more efficient
> > dispatch?)
>
> Are you talking about multiple dispatch viewed as a sequence of single
> dispatches?


No, I more meant that dynamically typed single dispatch can be
modelled as a sort of crippled multiple dispatch where the only the
first argument may have a type and each unique function definition
generates an implicit shadow-function handling the "method missing"-
situation.


> IMO, the implementation shall statically ensure that dispatch never fails
> at run time. This is trivial for single dispatch (solved through
> inheritance) and quite difficult for multiple one.


I am sorry but I don't quite follow you. What are you talking about
here?




/Christoffer



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.