On Tue, 2004-04-06 at 19:05, Frank J. Lhota wrote:
> When an Icon or Unicon procedure creates a co-expression, that co-expression
> maintains a copy of all the dynamic local variables of that procedure.
> Clearly, it makes sense to include copies of the dynamic variables actually
> referenced by the co-expression, i.e. those dynamic variable that actually
> appear in the "create" expression. But does it make sense for the
> co-expression to include copies of dynamic variables that are NOT
> referenced? Consider this example:
Keeping the 'invisible' dynamic variables is entirely an artifact of
the implementation. These variables 'exist' solely (ok, they used to,
and I'm assuming they still do...) as offsets from the the frame pointer
for the currently active procedure and it's much simpler to generate
the code for evaluating the co-expression by preserving those offsets.
(After all, that code generation is taking place as the rest of the
enclosing procedure's code is being generated.)
Getting rid of them (don't forget to include procedure parameters
as part of the set of dynamic variables) is probably a Good Thing,
but it does sound like a pain (i.e, better thee than me!).
Hmmm, isn't there a way to reference variables using a string form
of its name [no book handy to check, but something like var("foo")]?
If so, then getting rid of the hidden variables might be hard indeed.
--
Steve Wampler <[EMAIL PROTECTED]>
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
