Alexandre Ferrieux wrote:
> 
>  So the bottom line is: how to isolate cases where locals (and proc 
>  parameters as a special case) are handled in a completely traditional 
>  way (like in C), and hence can be moved to the stack, right ?
> 
>  -Alex
Hi Alexandre

The short answer is that you can't really scan a Tcl proc to figure out 
if it does not make use of upvar or
other linked variables. You can write a compiler that assumes that a 
proc does not deal with linked variables,
but it is trivial to create a test case that breaks this optimization. 
And in the real world, the code would "break"
without the user ever knowing something went wrong or why. Here is a 
quick example:

proc scan_me {} {
  set var 0
  some_other_command
  return [expr {$var + 1}]
}

proc some_other_command {} {
  upvar 1 var local
  set local "Foo"
}

The compiler has no idea what "some_other_command" does, so it might 
assume that "scan_me" is ok to optimize.
But, if you just invoke the other command and set the interp result to 
1, the code will not work correctly.

P.S.
If you are looking for test cases for compiler related Tcl issues like 
this, I suggest you have a look at the tjcruntime
package in the tcljava CVS:

http://tcljava.cvs.sourceforge.net/tcljava/tjcruntime/varcache/

cheers
Mo DeJong


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