Re: Proposed vtable changes WRT method lookup
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. ... 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 Cdispatch is (will be) a vtable you can always plug in the desired dispatch system in your metaclass. Matt leo
Re: Proposed vtable changes WRT method lookup
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 Cdispatch 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. -???
Re: Proposed vtable changes WRT method lookup
[ 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? Finding the correct MMD function is always the same algorithm. Having that functionality in one place (the metaclass) is cleaner IMHO. No. It is not always the same algorithm. Perl 6 uses manhattan distance. Yes. I meant inside one class (HLL) system. Matt leo
Re: Proposed vtable changes WRT method lookup
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) ...). But the crux of my idea is the following breakdown of responsibility First meta-class provides class resolution list for a particular class heirarchy (mro). This will work because the metaclass is known at class construction time and will thus know the full object heirachy for the class, objects that dynamically change their parents will go through their meta-class to do this. Second meta-methods provide the dispatch to specific multimethods based on the class resolution list (and possibly value of) their arguments. This allows different languages to provide different class resolution lists, while still enforcing a single dispatch metric for each function, but possibly different dispatch metrics for different functions with the same arguments. Finding the correct MMD function is always the same algorithm. Having that functionality in one place (the metaclass) is cleaner IMHO. No. It is not always the same algorithm. Perl 6 uses manhattan distance. Yes. I meant inside one class (HLL) system. The problem I see with that is calling a MMD function with arguments from two different class systems. It would make more sense to me to separate the dispatch system and the object system. The essential motivations for this is you avoid interaction of different dispatch systems (which could be quite confusing). Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Proposed vtable changes WRT method lookup
Dave Whipp [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
1) rename vtable-data to vtable-class
All current usage of the 'void *data' vtable element is as the object's
class. So it should read PMC *class.
Its a minor thing, but I would try to avoid using identifiers that are
keywords in C++: especially in header files.
Aren't struct members in a distinct namespace? It's like:
typedef struct _vtable {
...
PMC *class;
...
} VTABLE;
But it could of course read Cclass_pmc or such.
Dave.
leo
Re: Proposed vtable changes WRT method lookup
Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: Below inline attached is a proposal for vtable changes, mainly WRT method lookup. First, a general question: under what circumstances is it OK and/or expected for the opcode Cgetclass and the VTABLE entry VTABLE_get_class to return different results? No. The opcode should just call VTABLE_get_class() and return, what that method returns. At the moment, these return quite different results for all of the standard PMCs. The Cgetclass opcode currently returns, what the type registry Cclass_hash provides. This is ok for the standard PMCs, because the registered class is Cvtable-data. But the opcode should just call VTABLE_get_class(). The more general observation behind this question: if Parrot is going to provide a mechanism by which a class can override get_class, then the runtime should depend on such interfaces instead of bypassing them and attempting to standardize on mechanisms. Yes. The proposed changes are one step towards that goal. I'd like to have a standard interface for classes, a default implementation for Parrot core PMCs and Parrot standard objects, and all the phases of class manipulation should of course be overridable, i.e. the individual methods are all called through vtable functions. - Sam Ruby leo
Re: Proposed vtable changes WRT method lookup
All~ On Tue, 18 Jan 2005 10:18:52 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Sam Ruby [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: Below inline attached is a proposal for vtable changes, mainly WRT method lookup. First, a general question: under what circumstances is it OK and/or expected for the opcode Cgetclass and the VTABLE entry VTABLE_get_class to return different results? No. The opcode should just call VTABLE_get_class() and return, what that method returns. At the moment, these return quite different results for all of the standard PMCs. The Cgetclass opcode currently returns, what the type registry Cclass_hash provides. This is ok for the standard PMCs, because the registered class is Cvtable-data. But the opcode should just call VTABLE_get_class(). The more general observation behind this question: if Parrot is going to provide a mechanism by which a class can override get_class, then the runtime should depend on such interfaces instead of bypassing them and attempting to standardize on mechanisms. Yes. The proposed changes are one step towards that goal. I'd like to have a standard interface for classes, a default implementation for Parrot core PMCs and Parrot standard objects, and all the phases of class manipulation should of course be overridable, i.e. the individual methods are all called through vtable functions. It looks like we are creating ourselves a reasonable subset of the Common Lisp Object System here. Given that CLOS was created to allow Lisp programs to modify their objects' semantics to those of a different dialect of Lisp, perhaps we could learn from their structure. We have an mro array just like CLOS, we have a class PMC just like CLOS. If we add to it support. MMD, however, is where things begin to differ. Instead of havng the find_method with the extra mmd_nr, we could have a MMD_Resolution PMC which would then get the mro from each class, and figure out which method to call based on that. Logically this would make some sense as no single class can have the smarts to do MMD since it depends on all objects involved. This also allows each MMD function to dispatch according to the language which defined the function (and thus the MMD_Resolution PMC for that function). Hope that makes sense, Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Proposed vtable changes WRT method lookup
Matt Fowles [EMAIL PROTECTED] wrote: ... If we add to it support. MMD, however, is where things begin to differ. Instead of havng the find_method with the extra mmd_nr, we could have a MMD_Resolution PMC which would then get the mro from each class, and figure out which method to call based on that. That was Cvtable-dispatch in the proposal. Cfind_method is just called to query one object or class, if it can do the method. Finding the final (MMD) function is done separately with a distinct vtable method (and probably implemented inside some meta class PMC). Hope that makes sense, Yes. Matt leo
Re: Proposed vtable changes WRT method lookup
Leo~ On Tue, 18 Jan 2005 16:52:52 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Matt Fowles [EMAIL PROTECTED] wrote: ... If we add to it support. MMD, however, is where things begin to differ. Instead of havng the find_method with the extra mmd_nr, we could have a MMD_Resolution PMC which would then get the mro from each class, and figure out which method to call based on that. That was Cvtable-dispatch in the proposal. Cfind_method is just called to query one object or class, if it can do the method. Finding the final (MMD) function is done separately with a distinct vtable method (and probably implemented inside some meta class PMC). That makes sense. If the vtable-dispatch method is attatched to some PMC, what provides that PMC? Is it the MMD function being called (what I would suggest), some environmental one, or something else? Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Proposed vtable changes WRT method lookup
Matt Fowles [EMAIL PROTECTED] wrote: Leo~ On Tue, 18 Jan 2005 16:52:52 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: That was Cvtable-dispatch in the proposal. Cfind_method is just called to query one object or class, if it can do the method. Finding the final (MMD) function is done separately with a distinct vtable method (and probably implemented inside some meta class PMC). That makes sense. If the vtable-dispatch method is attatched to some PMC, what provides that PMC? That PMC is the metaclass PMC of the class system. For standard Parrot objects that's mostly default.pmc or parrotclass.pmc and/or an implementation in src/objects.c. ... Is it the MMD function being called (what I would suggest), some environmental one, or something else? Given a P6 function call (which can be MMD or not): foo($a, $b, $c) If nothing is kwnown about foo, this would be basically: func = a.dispatch(foo)# VTABLE_dispatch(interp, a, foo) invokecc func That ends up in default.pmc's implementation normally, which calls Cfind_method repeatedly according to Cvtable-mro and the algorithm described in MMD and VTABLE_find_method. Matt leo
Re: Proposed vtable changes WRT method lookup
Leopold Toetsch wrote: 1) rename vtable-data to vtable-class All current usage of the 'void *data' vtable element is as the object's class. So it should read PMC *class. Its a minor thing, but I would try to avoid using identifiers that are keywords in C++: especially in header files. The fact that Parrot is pure C doesn't mean that no one will attempt to use a C++ compiler on it in the next 20 years. I've been bitten by this sort of thing too many times. Dave.
Re: Proposed vtable changes WRT method lookup
Leopold Toetsch wrote: Below inline attached is a proposal for vtable changes, mainly WRT method lookup. First, a general question: under what circumstances is it OK and/or expected for the opcode Cgetclass and the VTABLE entry VTABLE_get_class to return different results? At the moment, these return quite different results for all of the standard PMCs. The more general observation behind this question: if Parrot is going to provide a mechanism by which a class can override get_class, then the runtime should depend on such interfaces instead of bypassing them and attempting to standardize on mechanisms. - Sam Ruby
