On 17 Sep 2002, Juergen Boemmels wrote:
> You do something like push_pad implicitly in the Sub class, but
> without a corresponding op in core.ops, when you invoke the Sub.
> You also get the current lexical scope implicitly at Sub creation
> time. This may be intentional so that the bytecode cant mess with the
> lexical stack, but there are already. new_pad and pop_pad.
Right. As I understand it, the idea is to have a very controlled
interface to lexical scopes. So you can create a shallower or deeper
scope based on the current one, or restore a previously-saved scope, but
not manipulate scopes in arbitrary ways.
I think if you need fully general pad-manipulation, we should go for
something like {push,peek,pop}_pad to manipulate the pad stack where each
pad will look sort of like arrays of hashes. That means you can implement
scope-chopping like so
pop_pad Px
set Ix, Px
dec Ix
set Px, Ix
push_pad Px
and scope extension using and "inc" instead of a "dec" in the above
sequence. To go a step further, we could just wrap stacks as limited
arrays, then have a "get_pad_stack" op, and use normal ops for the rest of
the manipulations. I'm leaning toward this because it lets people who
think of new and weird things they want to do with scopes implement them
without having to kludge around a limited set of pad ops.
{find,store}_lex could either remain unchanged, or be eliminated in favor
of all-the-time keyed access.
> > Actually, referencing the static scope as a multidimensional array might
> > work as well:
> >
> > set P1, P0[2;"$foo"]
> > set P0[-1;"$bar"], 23
The stubs are in there for some of these, and they look pretty
straightforward to implement.
/s
