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:
Perl6: infix<+>(...) {...}
Python: __add__ = myadd or even c.__dict__.update(myops)
Both compilers have to create a multi sub or a method called "__add" in
Parrot and store the sub or method in an appropriate namespace either
via C<store_lexical, C<store_global>, or C<add_method>. If your compiler
doesn't allow to overload some core functionality, it ought to emit an
error and not install the overloaded function.
Parrot's builtin "__add" is still there, probably as:
ns = interpinfo .INTERP_INFO_ROOT_NAMESPACE
m = ns["\0__parrot_core"; "__add"]
a = m(b, c)
or
iclass = getclass "Integer"
a = iclass."__add"(b, c)
or similar.
But given the dynamic nature of our target languages, I don't see any way
to keep a "primitive" add_p_p_p opcode, which is BTW not more efficient
or faster.
> 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.
> 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
