Leopold Toetsch writes: > Luke Palmer <[EMAIL PROTECTED]> wrote: > > > I think we should replace our multimethod system with a more general > > pattern matcher, a "variadic multimethod" system of sorts. Multimethods > > need to be variadic anyway, because we want pugs's quicksort example to > > work. > > I'd not say replace. The dispatcher will very likely be a Parrot PMC. > The default dispatcher dispatches on types, matching variadic signatures > should be possible too. > > All infix operators are multi subs. I can't imagine that we want to pay > the penalty for simple operations like: > > $a = $b + $c > > to inspect the values of operands, constraints, rules and what not.
Having written several multi dispatch systems, I know that this is easy to optimize. If nobody has defined + on any fancy subtypes, then we can quickly fall back to a bitset-intersection dispatch algorithm on the types (or even, eew, direct lookup). If + has been defined on fancy subtypes, then we compile the quickest way to figure out whether none of the arguments are one of them, and fall back. This is a little tricky, but some elementary graph theory gets us there. Essentially, what dispatcher we're using for + depends on what kinds of +s people have defined. That's how it should be; otherwise you'll get people globally overriding + so they can stick their own dispatcher in there, which isn't a portable solution. But we always have enough knowledge to optimize the hell out of this, and they're not not handwavy "we can probably" optimizations. They're real, and they're pretty darn easy. Luke
