Operator overloading revisited

[Christian Plesner Hansen]

> Costs that seem to leap out from Christian's mutual-asymmetric multimethod
> proposal:
>
> 1. Two lookups, "this+" and "+this", required.
> 2. Intersection.
>
> (2) looks like a transformation or simplification of standard multimethod
> Class Precedence List usage to find the most specific method. Any system
> allowing multiple methods for a given operator will have something like it.
>
> (1) seems avoidable, though -- *assuming* it is not a phantom cost. We have
> to deal with the symmetric vs. encapsulated issue, though. But notice that
> Christian's proposal does not use "this" in the method bodies!

The really nice thing about this from a cost standpoint is that it
caches well.  If changes to the operators understood by an object are
reflected in the object's hidden class (to use v8 terminology) the
same way changes to methods are, all the same caching techniques can
be used.  A global (hidden class, hidden class, operator)->function
cache can be used to ensure that the full operator resolution only has
to be done once for any operand type pair, after which the result can
be fetched by a simple hash table lookup.  Similarly, inline caching
can ensure that the hash lookup only has to be done once for any
monomorphic call site; megamorphic call sites, which I would expect
were rare, would have to do a hash lookup but not full operator
resolution.

By the way, did you say "mutual-asymmetric multimethod" :-)?

> Function.defineOperator in the proposal binds both "this+" and "+this". I
> agree these should not be plain old properties. But then why spec them as
> named internal properties of any kind?
>
> Suppose we had a generic function "+" (syntax TBD) to which methods
> could be added for particular non-conflicting pairs of operand types. Then
> the lookup would be for two types A and B, but this can be optimized under
> the hood. See, e.g.,

Methods live on objects and their prototypes.  Operators should too.
Using a special internal property rather than plain old properties is
fine by me but they should be directly associated with the objects
involved.  I'd argue why that is so important but I'd like to be sure
I understand what you're proposing as an alternative.  As I understand
it you would associate the operators with the constructor functions
similar to python's five minute multimethods.  Is that correct?