Andreas Leitgeb wrote:
>  I'm thinking about a different approach to stack-variables:
>  
>  Explicitly declare stack-variables as such, and for these, upvar
>  from called procedures just won't work, neither does adding traces
>  to such variables, nor would these variables be visible to
>  [info vars] (not even in the same procedure).

Not good. But what you could do instead is to define a new type of
variable record that keeps the actual storage space for the variable's
contents on the stack (and which [trace] will refuse to touch). You
could probably make that work fairly easily, and the variable records
would be just one more thing generated during compilation. After all,
that's pretty much what we do right now anyway, except that the storage
space is currently a C array of standard Var structures. Since all
access to variables is through a pretty small API (except in TEBC)
making the code work with this is practical.

>  I'm sure there exist still more problems, afterall this is just
>  brainstorming and not a TIP (yet, not even for 9.0) :-)

;-)

Donal.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core