> We need a multimethod dispatch for vtable calls. Right now we're > working on a "left side wins" scheme and, while we're going to keep > that (sort of) we really need a way to choose the method to call > based on the types on both sides of binary operators. (Unary > operators, luckily, are easier)
Woot. Woot. I'm glad to see that we're going to get multi-dispatch in the parrot core. There's a few main methodologies: Lookup logic: a) Have the dispatch logic be intelligent, and lookup the appropriate dispatch in order of increasing generality. b) Have the dispatch just lookup in a table, and generate that table at load/bind/etc time with the logic of inheritence, generality, etc. You can generate a large table that's N^2 for N = number of PMCs. Easy on lookup logic, bad on cache and memory usage. With option a) above, there's a few techniques you can use: a) Dan's preferring (I think he is, anyway) a two-level lookup (so that if you don't need the multi-dispatch, it can be nearly as fast as regular dispatch. So we dispatch to left-side. It can be greedy and handle it, or perform the second-level lookup itself, giving full multi-method dispatch. (Extending to trinary dispatch and more should we want that.) b) You can probably use a hashtable as a sparse matrix. Perform repeated lookups until you get a non-null method. Most PMCs will only have specially-designed interactions with a small subset of family PMCs, if anything at all. I'm sure there are other techniques...I posted links to a bunch of 'make multi-dispatch fast' links back when I was arguing about this topic awhile ago. But I admit to not having read them, so there are likely to be many other techniques that my current brain dump doesn't cover. :) > We can do this with the current vtable scheme as it is, since we > already have a slot to put this in, and I think we're going to have > languages that still do a left-side-win scheme. Well, for one, the current vtable scheme does a lot more than operators, so I don't think anyone would argue for it going away. And even left-side-win schemes are merely a special-case of generic multi-dipatch, with the right side being a '*' to match all PMCs. Of course, if Perl is going to be multi-dispatch to the core, is there a valid argument for trying to optimize the single-dispatch case? Granted we already have that implemented, but some multi-dispatch schemes impose the same penalty for single- as they do for multi-. Would these schemes be allowed, or explicitly disallowed? Finally, my last item that I'd like to see included in any multi-dispatch scheme that gets implemented, is the ability to register methods to be called, that aren't in either PMC. While this is infringing a bit on p6-language territory, I still believe we need a mechanism for it internally. It would give a way for different mathematical libraries to interoperate in code, by merely writing operators which could handle the conversion from one type to another (or faster, dealing with the internals of both). Finally, I'd like to be able to use multi-dispatch for the purpose of conversion/casting. While the _as_int methods handle the simple ones fine, PMC->PMC conversions are essentially multi-dispatch, and imo, should be treated as such. This might only matter with strong typing, but it might also help with the differently-organized mathematical libraries: assuming no binary operators are written, one only needs to write conversions, to allow them to interoperate, if slowly. Thoughts? Am I taking it too far? Mike Lambert
