> Yes. We will, for actual method and sub dispatch. Not for the other > vtable methods, though.
I guess my big 'complaint' was against using vtables for the variety of operators, due to the inherent asymmetry in them. I knew Perl6 is going to have MMD, but I didn't know how deep that support is going to be. If it's just a layered-on language level construct, then it'll be just like Perl5 support for Class::MultiMethods. If we can get it a bit deeper, then we can use it to support Perl6 operators, such as add, etc, which was the main reason of my original email. I figured tho, that it might be nice to implement it at the Parrot level, for a few reasons. It's in C, so we can get more speed. If we define, for example, a 'conversion' operator with PythonInt,PerlInt as the dispatch type, then we can automatically have inter-language conversion support. I'm sure XS code has all sorts of macros for changing C strings, to Perl strings, to Unicode strings, and so on. This multimethod dispatch would make that work at the Parrot level, and just further the goal of inter-dynamic-language co-operation. > >In my opinion, this would provide > >several benefits over the current system. While (IMHO) MMD provides many > >benefits over the current system in terms of extensibility and ease of > >maintainence, it is still a superset of single-dispatch systems, and could > >easily be made to support non-MMD languages like Python, Perl6, etc. > > Don't assume perl 6 won't me MMD. It likely will. (I'd actually be > really surprised if it wasn't, but we haven't gotten there yet) I just didn't want to assume that Perl6 *will* be completely MMD.. If it is, great, but I don't know at what level there will be support for it. It may go against the grain of everyone who's been taught that OOP is the one true light. But I suppose those people aren't using Perl anyway. :) > It's not a lack, really. It's a deliberate design decision, and one > made specifically for speed reasons. It saves an extra, relatively > expensive, comparison for most of the operations. > > The core vtable methods need to be as fast as we can possibly make > them--we don't want to drop speed if we can possibly help it. I understand that vtables have an inherent speed advantage over MMD, and I wasn't arguing that there wasn't. Rather, I was arguing that it would simplify many things. But that goes into the design versus speed debate to a degree, and I hear you prefer the speed side of any such argument involving speed. :) That being said, the entirety of multimethod dispatch isn't really needed if the types are known at compiletime. Since we know the types of the two operators in the bytecode, the programmer is essentially doing a manual multimethod dispatch. I just wish there could be a greater sharing between this approach and the higher-level approach involving MMD on PMC's, since they aren't entirely seperate. But I guess I'm entering the realm of wishful thinking... > Why? They're base types, really. I'd like to add in support for > complex numbers too, but I've not yet gone that far. Might next week, > you never know. Say there is now complex support and bignum support in the core Parrot engine. In order to have the most complete implementation of complex, so that the user couldn't possibly have a need for anything else (bit of sarcasm in that..), complex would need to use bignums for both elements, or at least handle the switch between ints, bigints, and bignums. If bignum*complex goes to the bignum vtable, and complex*bignum goes to the other, these two different classes now need to operate on each other, and include distinct support for the other type, in their own class, in fact including the same code in both places because of their similarity. MMD's approach would allow for that, but it would also the same function to be used for both variants of the operation if you so desired, where it handled the interaction between the two distinct mathematical types in a bignumcomplexinteraction file, instead of splitting it between bignum and complex. > Complex numbers are an issue. Matrices aren't--they're a form of > aggregate, and they get handled elsewhere. Complex and bignum's support most of the mathematical needs. But are these part of a 'core' system that's Parrot? I could see an argument for using them as a core Parrot library, but I can't see any logic for how these fit into core Parrot itself. In fact, by making these types of things part of the core, you make them ignorant of non-core things, and can actually make other operations more difficult (see next paragraph). As an example for matrices, however: Say we have the matrix PMC, and the bignum PMC. Now I multiply a bignum * matrix, or matrix * bignum. In these two cases, one goes to the bignum vtable, and one goes to the matrix vtable. Since bignum is in the core, it's very unlikely to have knowledge about this user-created matrix PMC. How then, will the user ever be able to make a bignum * matrix work correctly, if that gets dispatched to bignum's add(PMC* pmc) vtable method all the time. With MMD, they could simply add support themselves for interfacing their matrix class with the various kinds of core PMCs, like bignum and complex numbers. I'll probably drop this point soon, as I'm not likely to make any headway with changing the current approach, but I want to know that I at least tried, so I don't have any regrets about not even attempting to change the direction of Parrot, at some point in the future. :) Mike Lambert
