Heya, I was curious if anyone has ever considered implementing multimethod dispatch (MMD) directly into parrot. 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.
Parrot has been doing some questionable things, in my mind, to get around the lack of multimethod dispatch. First, there are basic native types such as num, int, and string, which I'm perfectly fine with. But what bothers me is the fact that bigint's and bignum's are being given a special place in the vtable. If we can't get these classes working with the base types properly without putting them in the core and vtable itself, how can we expect users to make such things as complex numbers and matrices mesh with the system? In MMD, A.add(B) in OOP terms would be dispatched to an add function specifically registered for A and B, instead of just calling add on A. This difference is not apparent when dealing with the parrot native types, since they already provide different functions for add_int and add_num. But if you're a PMC, as just about every perl variable will be, you get the generic treatment and are given an add, or at best, an add_same. I'm proposing to extend that to allow there to be different add functions for specific PMC types. Some might argue that this leads to an explosion of type registrations, since a single class must register itself with every type out there. This could be solved by allowing them to register a given function for PMC's in general (the existing way, basically), and allow a few specific functions for specific types they would like to handle directly. MMD would also allow users who had code that dealt with Math::BigInt and Math::BigInteger to write routines to coerce between the two types *without* requiring participation of the original module writers or editing of those packages. They could write something for add(BigInt,BigInteger), coercion functions, and suddenly their two incompatible pieces of code will be able to work together, hopefully seamlessly. With parrot, this could be implemented to allow Perl* types to interact with Parrot* types, providing automatic conversion and interaction between the two types of PMCs, by whoever decides to make the interface work between the two languages. This wouldn't require any additions to the perl* types or parrot* types, but could be written independantly, and registered with the parrot system at loadtime. Others might say that multimethod dispatch is too slow. There are numerous papers out there on implementing multimethod dispatch efficiently, such as: http://citeseer.nj.nec.com/amiel96fast.html http://citeseer.nj.nec.com/495443.html http://citeseer.nj.nec.com/ferragina99multimethod.html http://citeseer.nj.nec.com/330853.html http://citeseer.nj.nec.com/pang99multimethod.html and so on and so on... I haven't read them myself, but a quick search proved to find many available papers out there. Regardless, MMD will still be slower than the current parrot vtable dispatch system, and that point is unavoidable. One could argue that vtable dispatch is slower than a generic 'add' function, too. But the benefits provided by vtables to avoid spaghetti if/else code more than outweigh the disadvantages. I'd argue that the same logic would apply to MMD as well. Finally, here's a real-world example of code that could be improved. :) perlint needs to handle addition to strings, nums, ints, perlstrings, perlnums, perlints, and other pmc's. The first three are covered by their individual functions, the next two are implemented by if/else's in the generic add function, and perlints get called via add_same. This variety of function names and approachs just seems wasteful, and MMD could potentially simplify a lot of this into one function per type, with a consistent scheme. Any thoughts or comments on this? Is this a case of 'patches welcome' for the current system, but no one's seen a need for it? Or is there an argument against implementing MMD in the core parrot? Sorry for the long email, but I wanted to get this off my chest in case it's possible to change things, before we get too ingrained with the current method. Thanks, Mike Lambert
