Alexandre Ferrieux wrote:
>  Now even for upvar, there are possibilities. Since in Tcl [upvar]ed vars 
>  are accessed at runtime, it suffices to maintain enough data for a name 
>  lookup in each stack frame.

You are aware that this is very close to what we actually do? :-) The
main difference is that variables aren't on the stack anyway, because
values and variables are different things in Tcl. (This is mainly to
allow coupling of variables together - how [upvar] and friends work -
and to provide a place to hang traces off the variable.)

>  This may sound of only academic interest. I'm not that sure, because the 
>  Forth community has a track record of concern for speed and JIT compilation.
>  Cat already has a conversion from its bytecode to CIL. I would not be 
>  surprised to see a JIT for x86 come into life.

The main tricky bit is probably dealing with traces. Traces are nice on
one level (they make certain styles of programming *easy*) but their
implementation remains one of the scariest bits of Tcl. It's possible
that it might be possible to implement some kind of code to determine
that a procedure is in fact trace-free though, and so enable more
extensive optimizations than at present. That'd be very cool, and would
allow code to get *much* faster.

The best summary I can come up with though is that this area is very
difficult to work in, but probably will admit a smart solution that wins
big-time. Not that I'm planning to get quite that smart today... :-D

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