Mo DeJong wrote:
>  If you ask me, the right way to create an optimized Tcl compiler is
>  to provide a way to declare procs that don't "do anything funky".
>  This includes upvars, uplevels, traces vars, and so on. Basically, a 
>  proc would declare that it will not mess with variables in calling 
>  scopes and that other procs invoked by the command will not mess with
>  variables in the current scope. The runtime would also need to ensure
>  that crazy edge cases like the "set" command being redefined while
>  the proc is running don't happen.

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.  This starts 
rooted in the core bytecodes and epoch handling.  A proc can only be 
flagged SIMPLE if it contains no side-effect functionality.  The simple 
proc that Mo provided would qualify, because it is 100% bytecoded.

Anything with known side-effectors (upvar, uplevel, etc) and/or 
call-outs of unknown result (EVAL_STK) cannot be declared SIMPLE.

This would also work if you redefine set, as you reset the epoch.  If 
the redefinition of 'set' is a SIMPLE proc, then other procs could still 
be flagged SIMPLE upon their recompilation.

Right ... that was easy.  Who was going to code it up again? ;)

-- 
   Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/

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