On Mon, May 28, 2007 at 05:18:47PM -0700, Jeff Hobbs wrote:
>  I would think that this would be theoretically "not too difficult", in 
>  that you build up as you go along.  All proc compilation could consider 
>  adding the extra flag TCL_SIMPLE_PROC in the bytecode.

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).

There is of course a downside: either, one cannot do anything with
them (as set,incr,... also do C-coded upvar),  or we would be 
faced with a set of privileged commands that can still access these 
stack-vars without a tcl-way to mimic them.  Bad. not Tcl-TAO.

This reminds me of Hecl's approach, where rather than have the called
procedure freely rummage in caller's stackframe, the caller passes
references (pointing to the variables, rather than just naming them) 
to the called procedure... 

This could be done such, that if the bytecode compiler recognizes
a stack-var-name as constant argument to a proc, it would make that
a special object with the stack-var-name as string-rep, plus some
information to find the variable in the caller's stack, which "upvar"
in the callee could still use.  Since such references do not make
sense to send over sockets, store in files,etc it wouldn't matter that
any manipulation on the reference (any that destroys object info) would
then destroy the connectibility.  Just like a "file42" whose channel has
been closed.  Once the variable is upvar'ed, it could either inherit
it's stack-ness (I'd prefer that), or be promoted to a normal local
variable in the callee.
That way, stack-vars could still be passed by reference like normal
variables.

Only problem left: what happens, if some callee creates a new variable
in the caller with a name that existed in the caller as a stack-var?
Could it be detected/prevented/handled in any sensible way?

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

-------------------------------------------------------------------------
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