On Thu, 1 Aug 2002, Jerome Vouillon wrote:

>  On Wed, Jul 31, 2002 at 11:22:56PM -0400, Melvin Smith wrote:

>  > We chose to implement

>  > the access as ops, and you prefer using a PMC Array directly. I can

>  > at least see one advantage to the explicit ops: they don't require

>  > a register to use them in the general case.

> 

>  [snip]

> 

>  But I'm especially frightened by opcodes such as new_pad.  The Perl

>  compiler may well be able to perform more optimizations if it does not

>  use this opcode but rather generate specialized code.


Putting my "amateur compiler writer" hat on for a moment, I'll have to
agree for a couple of reasons.  First, supporting Perl 6's introspective
features (e.g. %MY) is much easier if the internals and language
implementation use the same data structures where practical.  Sure, it's
possible to write some glue code to make a stack act like a PerlArray, but
it's more work, and in this case I'm not sure it's necessary.  There is
the unfortunate fact that all of a sudden the lexical implementation will
be tied to a particular language's PMC's, but this seems like another
reason to push lexicals out of the interpreter core.

Second, I've been playing with implementing lexicals "the right way" in
P6C, and haven't really found new_pad and pop_pad all that useful.  Of
course, I don't have a working implementation yet, and I may be completely
misunderstanding how the ops should be used.  I suspect that getting them
to "do the right thing" would involve adding lex-playing-with code to bsr
and ret, plus maybe a couple more ops.  Plus adding more ops to push
lexical stacks onto the lexical stack-stack (for your Befunge fans ;).

>  So, I would feel more comfortable trying to reuse existing opcodes for

>  the moment, especially as I don't think we have a clear view of the

>  "right" way to implement lexical variables yet.


My naive implementation would have an array of hashes for each sub, with
one entry for each level of scope within.  This is just like the
pad_stack, but implemented using only language features.  (Dynamic)
lexical lookup works its way through this stack.  Static lookups can
probably be resolved to registers, with code inserted to fetch values out
of the pad the first time they are used, and store them back when a scope
is exited.

Returning a closure would make a copy of the scope array, containing
references to the pad hashes (here's where GC makes me happy, and where I
may make the GC unhappy).  So the Sub PMC has a code pointer and a scope
stack pointer, which is either set up automatically when creating a new
Sub, or is accessible as a method.

Another alternative would be single-level pads for each scope containing
all accessible lexicals.  Unfortunately, I think %OUTER and %MY make this
very complicated (or impossible) to get right.

Waving my hands somewhat more quickly, as an optimization, lexicals can
just live in registers when the compiler sees no references to %MY or
closures.  Nastiness like eval and caller.MY can be handled by inserting
fixup code to reconstruct the lexical array on demand.

Hopefully I can get some of this working soon, and put it up on the list
for people to play with and improve.

/s