From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 28 Mar 2005 11:27:58 +0200
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.
Seems to me that depends on the compiler . . .
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.
I guess I was hoping for access to a lower-level mechanism. FWIW,
Common Lisp is an example of a dynamic HLL that doesn't allow certain
ops to be overloaded (at least not directly). But the existing "add" is
already too generic, so I'd have to fake this with explicit type checks
anyway. Oh, well.
> 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.
I'm afraid I don't understand; how is "int" different from "Int"? And
why would one need both?
> ... 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.
Great; glad to hear it.
-- Bob Rogers
http://rgrjr.dyndns.org/
