On Nov 22, 2005, at 11:06 AM, Leopold Toetsch wrote:
dynclasses/dynlexpad.pmc provides (or should eventually provide) a
more dynamic lexpad (similar to the deprecated scratchpad.pmc).
It's not finished yet, it doesn't consult LexInfo for static
lexicals yet.
Before working more on it, I'd like to know from HLL authors, what
they need.
Currently it looks like this
SYNOPSIS
.sub _load :immediate # (1)
$P0 = loadlib 'dynlexpad'
.end
.HLL "foo", "" # or "foo_group" - load dynamic PMCs too
.HLL_map .LexPad -> .DynLexPad # (2)
I'd like to provide an easy way to provide this mapping for language
developers so the users of the language don't have to remember to add
the second line whenever they use, e.g. Tcl.
I could add another 'pmclass' keyword for this, but it would only
really be needed once in the shared library, so lang authors would
have to pick one PMC and add it there, so...
Seems like the cleanest thing to do is add a subclass for DynLexPad
(with no overrides) and map it in the PMC definition to LexPad. Does
that sound reasonable? The main problem I see with doing this in the
PMC is the dynamic-pmc nature of DynLexPad, which makes me wonder
what the PMC code for a subclass would actually look like.
.sub main :main :lex # (3)
$P0 = new .Integer
store_lex 0, 'a', $P0 # (4)
...
$P1 = find_lex 'a' # no pad_depth (yet)
.end
DESCRIPTION
(1) The :immediate sub is run before the parsing proceeds, the
DynLexPad is already avialable at (2) so that .constant syntax
works. (2) installs for the given HLL named "foo" the DynLexPad as
the one to be used.
(3) denotes the main sub as needing a lexpad (see also pdd20)
(4) stores the lexical into the DynLexPad hash as a new entry. The
'pad_depth' integer is needed for an initial store_lex, but
otherwise ignored, specifically it doesn not allow (yet) a store
into an outer lexpad.
See also t/dynclass/dynlexpad.t and dynclasses/dynlexpad.pmc
Comments welcome
leo
