Related articles |
---|
[2 earlier articles] |
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) |
Re: Best multimethods/multiple dispatch implementations? gneuner2@comcast.net (George Neuner) (2008-09-19) |
Re: Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-22) |
Re: Best multimethods/multiple dispatch implementations? gneuner2@comcast.net (George Neuner) (2008-09-24) |
Re: Best multimethods/multiple dispatch implementations? armelasselin@hotmail.com (Armel) (2008-09-24) |
Re: Best multimethods/multiple dispatch implementations? lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-25) |
[7 later articles] |
From: | =?ISO-8859-1?Q?Christoffer_Lern=F6?= <lerno@dragonascendant.com> |
Newsgroups: | comp.compilers |
Date: | Thu, 18 Sep 2008 01:50:16 -0700 (PDT) |
Organization: | Compilers Central |
References: | 08-09-026 08-09-069 |
Keywords: | OOP |
Posted-Date: | 18 Sep 2008 18:08:02 EDT |
On Sep 16, 1:17 am, George Neuner <gneun...@comcast.net> wrote:
>> I know Dylan and CLOS also has implementations, but I heard CLOS'
>> might be pretty slow.
>
> CLOS dispatch is typically implemented as an inline coded minimum
> depth discrimination tree - a series of IF-THEN tests on the argument
> types - ordered by the partitioning value of the function arguments.
> Lisp tries to order the tests so as to most efficiently partition the
> virtual search tree at each step.
The best case scenarios of this ought to be really fast and easy to
inline, but what about methods that are frequently overridden?
Wouldn't worst case be pretty bad?
> It is quite feasible to have both object bound methods and separate
> generic MD functions in the same language. You could use the same MD
> dispatch method for each, but method tables are more efficient for
> single dispatch. MD tables can get very large but they are mostly
> sparse and so can be compressed effectively. However, compressing the
> tables slows lookup at run time. This is ok if few MD dispatches are
> expected, but if you anticipate a lot of use, using discrimination
> trees like CLOS may be a better bet.
Aren't there some languages with hybrid dispatch using tables or trees
depending on the tree depth? With even rudimentary type inference I
suppose one would be able to cut away a lot of branching.
Do you know of any papers on CLOS dispatch implementations?
/Christoffer
Return to the
comp.compilers page.
Search the
comp.compilers archives again.