On Wed, 2004-04-28 at 12:33, Dan Sugalski wrote:At 12:21 PM -0400 4/28/04, Aaron Sherman wrote:
>Since we're specifically talking about Perl here (and probably not Perl >5, since its overloading model is baroque and probably has to be managed >by the compiler, not Parrot)
Actually perl 5's overloading gets handled this way too. Overloaded operations *can't* be handled by the compiler in dynamic languages, and none of then do so.
Hmmm, I thought we were on the same page here, but I'll back up and define terms if needed.
When I talk about a runtime construct being "handled by the compiler" vs "handled by parrot", I mean that the compiler will have to generate code that knows how to deal with the construct, rather than relying on Parrot's native constructs.
Right. That can't, and doesn't, work.
Take a look at pp.c (I think--might be pp_hot.c) in perl 5's source distribution to see how perl 5 handles it now. Basically every function that can be overloaded must first check to see if either side does and, if so, does the dispatch. That's what parrot has to do, only we skip the checks and just go dispatch. (Which is faster, generally. Go figure)
We lose a bit of speed over the current parrot scheme of leaving it to the vtable function to check, but given that all the major languages would have to check anyway, it's not any loss, really. And saves a dispatch as we don't have to do the vtable func dispatch.
You seem to be replying to a point I would not make, e.g., that the compiler would have to somehow determine at compile-time what would happen. Clearly that's impossible.
Right, but you're assuming you can put this in the RTL. You can't, and it isn't there in any of the other dynamic languages that do overloading. (Which is what this is, essentially)
> >, I was under the impression that for types>that are non-objecty,
Types that are non-PMC won't check. PMC types will.
Ok, so in Boston you suggested that every variable declared by a high level language would have to be a PMC and that INT registers for example were only for the compilers and Parrot libraries to use... would that not be the case for a "Java int" or a "Perl 6 int" and/or has it changed since then?
Nope. If it's in a namespace or pad it's got a backing PMC, otherwise the introspective namespace walking stuff won't work right. The only difference there is that the compiler will be able to emit shortcut code and skip the whole PMC thing in operations in those cases where it's not needed.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
