Bob Rogers <[EMAIL PROTECTED]> wrote:
> IMHO, one can have too much overloading. It seems cleaner to
> distinguish between "+, the (sometimes overloaded) HLL operator" and
> "add, the Parrot addition operator" so that compiled code can opt out of
> the overloading when the compiler knows that it really needs to do mere
> addition.
The compiler doesn't and can't know that. The only way to be sure that
"add" isn't overloaded is in HLLs that have a notion of "closed" or
"finalized" classes. Python doesn't have such a construct. Therefore the
plan is to do a method lookup once (MMD search per default) and then
cache the result.
> Maybe we need just a fake "int" class for the sake of MMD.
> I think this is a really good idea. Indeed, I think it's hard to do
> otherwise; you need some place to store the "isa" relationships between
> PMC classes for primitive types.
It's probably not so much the "isa" relationship, but this bothers me:
infix<+>(int $l, Int $r) { ... }
has to look into the class of "$l" for MMD candidates.
> ... Beyond that, I think it's good to
> minimize the distinction between PMC classes and ParrotClass classes
> from the perpective of HLLs; implementors are then freer to use a
> ParrotClass to start, and reimplement as PMCs later for speed.
Yes. The distinction is already vanishing. E.g. both PMCs and
ParrotClasses now have the MRO field so that a method lookup is the same
for both cases.
> BTW, I just noticed that "pmclass ParrotObject extends ParrotClass
> ..."; is this right? Seems like the class and instance hierarchies
> ought to be disjoint . . .
I don't know, but probably yes.
> This is also how Common Lisp prefers to view the world.
Probably almost all HLLs except Perl.
> It also allows "$a = $a + $b" to have different semantics from
> "$a += $b" for suitably defined operators and values. Not that I can
> think of a reasonable example off the top of my head . . .
Yep.
> -- Bob Rogers
leo
