From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Wed, 30 Mar 2005 08:57:55 +0200
Bob Rogers <[EMAIL PROTECTED]> wrote:
> 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).
Overloading is a syntactic construct that the compiler supports (or
not). It's more or less explicit, though . . .
Thanks for taking the time to explain this; I appreciate all the bits.
I confess that I didn't understand this part the first time I read it;
the key, I think, is that you are assuming (as I did not) that each and
every language built on top of Parrot will define its own PMC classes,
even for primitive arithmetic types, when necessary to get the right MMD
operator semantics. Is this correct?
> already too generic, so I'd have to fake this with explicit type checks
> anyway. Oh, well.
Why? When Perl6 overloads e.g. infix<+>(Int, Int) it's overloading the
"__add" multi sub of the Perl6 class PerlInt. No Python or Lisp "__add"
method is involved here, nor Parrot's Integer.
One of my motivations for exploring Common Lisp in Parrot is summed up
in four letters: CPAN. So I expect to want to call Perl[56] code and
get back Perl data types for further mungery in Lisp (if I ever get that
far). It might be the right thing in that case to accept the additional
Perl semantics, but I'm not completely convinced. I tend to think of
operator semantics as being "language scoped," but perhaps this is just
personal bias, as I can't think of a really compelling reason why it
should be so. It may be just that I am not used to thinking in terms of
interactions between multiple languages.
But I am also concerned that a proliferation of low-level PMC types
will be an obstacle to interoperability. It seems simpler to me to
represent each distinct kind of mathematical object as a single PMC
class (e.g. for integers and complex numbers, but emphatically not
strings), and use different operator implementations to capture the
semantics of each language. But different languages will differ on what
should be distinct, and having language-dependent operators seems kinda
ugly, so it's hard to make a strong case for this. Besides, it would be
a major change from Parrot's current vtable-oriented design.
On the other hand, the new MMD arithmetic moves more of the semantics
away from the individual PMC class vtable methods and into the MMD
operator, so maybe it's not so far-fetched.
But all of this may just be a sign that I'm not yet sufficiently well
indoctrinated into Parrot culture to "get it." I'm still trying,
though. ;-}
> 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?
The lowercased "classes" denote natural C types in Perl6. Above
corresponds to an opcode:
op add(out PMC, in INT, in PMC)
add_p_i_p
which we don't have BTW. The "_i" stands for the native C type INTVAL.
leo
Then I would argue that whether something is in a register or not should
have no effect on MMD semantics. Suppose you pick some suitable PMC
class (e.g. Int and Float) which is representationally identical (or at
least you can go from PMC to register and back without loss), and define
that as the assumed class of all such registers? Seems to me that doing
anything else is likely to cause confusion without providing a useful
distinction. You wouldn't want the result of MMD dispatch to change
because the compiler got cleverer about assigning things to registers,
would you?
-- Bob Rogers
http://rgrjr.dyndns.org/
