1) Again the infix ops - yes

From a HLL point of view:

  add d, l, r               # PASM op
  d = l + r                 # PIR syntax
  d = l."__add"(r)          # method call
  d = "__add"(l, r)         # Perl6 multi sub function call

are all more or less the same operations.

In Parrot it's handled currently by:

  mmd_dispatch_v_ppp(interpreter, $2, $3, $1, MMD_ADD);

where a 2-dimensional MMD_table holds entries per MMD function
category for a type pair (l, r).

2) MMD_table setup

Even the static table creation is broken. The main problem is
inheritance. To get that right, I'd propose these steps:

- all MMD (and almost all plain vtable) functions in the PMC files are
  treated, as NCI methods. That's the same as e.g. Float.pmc:cos().
- all such methods (including) the handwritten like "cos" get two
  underscores in front of their method names
- a NCI method is created via C<enter_nci_method> when either the
  class or an abstract base class (like "scalar") implements the
  method, but *not* if it's a defaulted[1] method or inherited from
  another non-abstract class
- as the infix operators are multi subs, a MultiSub PMC is created in
  the __parrot_core (or _builtin) namespace, again with this mangled
  name, e.g.  "__add"
- the same scheme is used for dynclasses too

Now the dynamic MMD search C<Parrot_MMD_search_default_func> should
work (given that the builtin namespace "__parrot_core" is searched
too).

Then we can populate the MMD_table either in one go or dynamically.

3) MMD_table overloading

Whenever a MMD infix function is overloaded, we have to rebuild the
MMD_table. We have a hook C<Parrot_invalidate_method_cache>, which
clears the method cache for one or all classes. The MMD_table is to be
rebuilt too. This hook has to be eventually a notification event, so
that other threads can invalidate their caches too (if caches are
shared).

4) Further changes and possible optimizations

Perl6 has the notion of lexically scoped multi subs. If there is a
considerable usage of such beasts, the global MMD_table doesn't work
well as scopes come and go as the program executes.

I'm still inclined to cache this MMD (and more) information in a
PIC (polymorphic inline cache). The PIC approach has one major
drawback though: it doesn't work with read-only (mmaped or shared) PBC
files. It works best with run cores that can rewrite the bytecode.

But with one more indirection a PIC-like scheme can work with
read-only bytecode too (probably). E.g. the assembler emits instead
of the proposed:

  infix "__add", Pd, Pl, Pr

this opcode:

  infix (.MMD_ADD << 24) | n, Pd, Pl, Pr

This allows 256 different infix operations, the number C<n> is a
consecutive count per emitted C<infix> opcode. It serves as an index
into the polymorphic cache. The prederefed run cores can sill rewrite
the opcode to use a real inline cache, other run cores use the one
indirection to access the cache.

If we keep MMD_table, we have to compress it in the long run, it's
already beyond one MB size for core PMCs only.

[1] to complicate matters, we have two kinds of defaulted methods:
one kind throws an unimplemented exception, others have a useful
default implementaion. The latter category should be inherited.

Comments welcome,
leo