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) |
[13 later articles] |
From: | "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> |
Newsgroups: | comp.compilers |
Date: | Sat, 6 Sep 2008 10:51:13 +0200 |
Organization: | cbb software GmbH |
References: | 08-09-026 |
Keywords: | OOP, performance |
Posted-Date: | 07 Sep 2008 17:30:37 EDT |
On Fri, 5 Sep 2008 13:20:37 -0700 (PDT), Christoffer Lernv wrote:
> 1. What is state-of-art when it comes to multiple dispatch? From what
> I read so far it sounds that something like Self's PICs could also
> speed up multiple dispatch. Are there any implementations using
> something like that?
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.
> 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.)
> 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? I think this is infeasible, and it does not solve the problem
which multiple dispatch is supposed to do. That is consistency of
operations defined on tuples of possibly different types.
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.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Return to the
comp.compilers page.
Search the
comp.compilers archives again.