Leo~ On Thu, 20 Jan 2005 10:01:42 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Matt Fowles <[EMAIL PROTECTED]> wrote: > > Leo~ > > > On Wed, 19 Jan 2005 16:26:07 +0100, Leopold Toetsch <[EMAIL PROTECTED]> > > wrote: > >> [ cc'ed p6l ] > >> > >> Matt Fowles wrote: > >> > Leo~ > >> > > >> > On Wed, 19 Jan 2005 10:02:26 +0100, Leopold Toetsch <[EMAIL PROTECTED]> > >> > wrote: > >> > > >> >>But where does that PerlMMD PMC come from? Does the Perl6 compiler > >> >>generate one somewhere? > >> > >> > It is generated by the compiler. During compilation all of the > >> > different MMD functions will necessarily be parsed and compiled, when > >> > the first MMD function is compiled the compiler wil add a MMD PMC to > >> > the appropriate table. Each time a specialized version is compiled it > >> > will be added to the already created MMD PMC. > >> > >> Interesting. Where is this information coming from? Where can I read > >> more about that? > > > The general idea that I am explain here has its root in the CLOS MMD > > system. To define a set of MMD methods one calls (defgeneric foo (a b > > c) ...) to add a particular implementation one calls (defmethod foo > > ((Cat a) (Monkey b) c) ...). > > I smell some namespace pollution here. The namspace, where you ought to > place the "generic foo" MMD PMC, could already contain a non-multi > subroutine of that name. Second: S12 states that multi-dispatch can > degenerate to single dispatch on plain methods, which seems to imply > that the full MMD can't be handled by your proposed MMD PMC.
That is a problem for the HLL. Just as there could also be an existing variable foo, the question of namespace conflicts is one that must be handled by the HLL. Single dispatch can be viewed as degenerates MMD still. When a HLL sees method declarations, it creates an generic for each method and specializes it for each class in the heirarchy that implements the method. > > > ... But the crux of my idea is the following > > breakdown of responsibility > > Yep. That's the reason for splitting the functionality of find_method, > which currently does it all. > > > The problem I see with that is calling a MMD function with arguments > > from two different class systems. > > That'll be more fun, yes. But as long as the classes have a common > ancestor, a matching MMD function could exist. > > > ... It would make more sense to me to > > separate the dispatch system and the object system. > > Yes. But as C<dispatch> is (will be) a vtable you can always plug in the > desired dispatch system in your metaclass. My question is what happens in your scheme if you have to variables with different metaclasses. Do we just use the left most class's metaclass? Is there some odd interaction? The advantage to my proposal is that only the MMD's dispatcher deals is involved with the actual method selection, a metaclass is only responsible for creating the mro list used by the dispatcher. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
