{ First, let's have a little applause for Leo for implementing the new
lexical scheme in, what, a week? He says it was only a half-day's
work, too. Nice work, dude! }
First some background for those of you who haven't read pdd20:
* Read pdd20.
But if you don't have time:
* LexPads are PMCs that provide a hash-like interface to lexical
variables.
* Each call frame may optionally have a LexPad.
Now, on to the idea:
HLLs need introspection on call frames and their lexicals. I figure
the easiest way to support HLL introspection of call frames is to make
call frames be PMCs. They would have METHODs like:
get_sub() # returns the subroutine being executed
get_lexicals() # returns the LexPad, or Null if none
get_caller() # returns the parent call frame
etc. We'd probably only need one new opcode, if that: something like
$P0 = callframe
to return the current call frame, which could then be walked with
get_caller(). I suppose we could toss it a version that takes an
INTVAL like:
$P0 = callframe 1
to walk up that many frames.
(Also, incidentally, Continuations would have METHOD get_frame().)
Now on to the questions, mostly for Leo:
(1) If this were implemented naively, would it be a significant
slowdown?
(2) How about hacks/cheats to make it fast?
(2a) For example, what if the internal call frame structure remains
its current non-PMC self, and the C<callframe> opcode actually creates
a _wrapper_ PMC? The only downside to that I could see is that PMC
identity would not callframe identity, and I could live with that if
it kept things fast.
(2b) Or maybe the PMC could be created on demand - only when the user
asks for it - and then cached in the low-level call frame structure,
so that would only need to be created once? This seems like the best
choice, assuming GC issues are manageable.
--
Chip Salzenberg <[EMAIL PROTECTED]>
