On Thu, Aug 01, 2002 at 10:57:34AM -0700, Sean O'Rourke wrote:
> My naive implementation would have an array of hashes for each sub, with
> one entry for each level of scope within.
I would use an array of arrays or a linked-list of arrays. This is
hardly more difficult to implement (you just need to keep track of the
variable indices during compilation) and the generated code will be a
lot more efficient.
> 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.
You would probably need to store them back each time you perform a
function call. I think it is good enough for the moment to always go
through the stack.
> 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).
You don't need to make a copy at this point. Instead, the copy should
happen each time you enter a block containing lexical variables. (You
should also allocate and fill a new pad at this time.)
> 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.
caller.MY is especially nasty because you have to pay for it even when
you don't use it: you can't know whether a function has to support it
just by looking at the function code. It will be really tricky to
implement any optimization if one can write things like:
caller(1).MY{'$y'} := $x
-- Jerome
