Front page | perl.perl6.internals |
Postings from March 2002
Multimethod dispatch for parrot?
Thread Next
From:
Michel J Lambert
Date:
March 7, 2002 08:52
Subject:
Multimethod dispatch for parrot?
Message ID:
Pine.LNX.4.44.0203071145240.22833-100000@access.mit.edu
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
Thread Next
-
Multimethod dispatch for parrot?
by Michel J Lambert