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. That might be (as is the case with Perl 5 right now) that the construct is built into a runtime library, or it might be that the compiler generates special code inline. 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. > >, 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? I'm not arguing anything here, just trying to wrap my head around the scope of this change's impact. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
