At 09:26 PM 9/3/2001 -0400, Sam Tregar wrote:
>On Mon, 3 Sep 2001, Dan Sugalski wrote:
>
> > >avoid using a "call" opcode all over the place, right?
> >
> > No, more a "try and leave the bytecode sections read-only" hack.
> >
> > Imagine, if you will, building LWP and bytecode compiling it. It uses
> > private opcodes 1024-1160. Then you later build, say, MIME::Lite, which
> > uses opcodes 1024-1090.
>
>I was referring to the practice of having compilation units create private
>opcodes. Am I wrong in thinking this is a new technique deserving of an
>excuse for existence?
Not as such, no. Larry's idea is that calling most subs should be pretty
much the same as calling most ops, in which case there's no reason for them
to be different. It also means that we can yank out great chunks of what
perl currently considers ops (socket functions are the big example) into
loadable modules (read: extensions) that can be loaded and used as needed.
It also means that, if sub calls still end up being more expensive than op
calls, that modules which add new ops are possible. Load 'em in and they
patch the parser and add their op functions to the op table.
I'm not entirely sure how much this'll be used, but I really, *really* want
to be able to call any sub that qualifies as an op rather than as a sub.
> > * Integer, String, and Number registers 0-x are used to pass parameters
> > when the compiler calls routines.
>
>s/compiler/interpreter/, right?
Yup. Thinko there.
> > * Subs may have variable number, or unknown number, of PMC parameters.
> > (Basically Parrot variables) They may *not* take a variable or unknown
> > number of integer, string, or number parameters.
>
>I don't understand this restriction. Won't it make implementing variadic
>functions more difficult?
Varadic functions that take actual integers, floats, or strings, yes.
Varadic functions that take parrot variables (i.e. PMCs) no. That's what
many perl functions'll be doing anyway. Those are unprototyped and just get
a list passed as their first (and only) parameter in PMC register 0.
> > Don't consider this list final until I've had a chance to run it past
> > Larry. He might be thinking of allowing prototypes to change, or spring
> > into existance relatively late in the game. (In which case we probably get
> > a call_in_list and call_in_registers form of sub call)
>
>Or those other language designers you're wooing, right? The prototype
>stuff sounds pretty Perl specific.
The prototype stuff's actually non-perl-specific in a lot of ways,
'specially considering how lax perl tends to be about calling conventions
and such. Most languages define a fixed set of named parameters rather than
a varadic list. (Which they tend to handle badly--like, say, C, whose
vararg handling sucks dead badgers through 12" metal conduit)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
