atProcExit

[TODO: describe (only NRE-wiki page of relevance appears to be [L1 ]); rename the command to something more tclish?] Consequence of NRE.

Lars H: A thought: how is this different from what can be had through the age-old technique of creating a dummy local variable and putting an unset trace on it? Basic implementation:

 proc atProcExit {script} {
    upvar 1 atProcExitScripts arr
    set arr($script) {}
    trace add variable arr($script) unset "$script\n\#"
 }

MS 2008-08-26 First please note that this is mostly exploiting the infrastructure of tailcall for a different and possibly interesting purpose, but is definitely the least thought-out of the new unsupported commands. It might not be more than a "tech show-off" for NRE.

Now to the actual question: some of the differences are:

• no need to find a variable name that is guaranteed not to be used, even in procs that may create and manipulate variables with names coming from the user
• the state of the interp when the script runs: with the var traces, the proc's internal structures are still occupying the Tcl stack, and some of the code is still using the C stack. These run when everything is really gone, just like tailcall would.
• well defined execution sequence (LIFO), which your construct does not guarantee (it is possible to have this feature with variable traces by putting the scripts in a list and running them in order within a [catch])

Lars H: OK, so mostly cleanliness differences. Executing when the proc is gone (tailcallishly) could actually be considered a disadvantage, because it is easy to imagine at-exit scripts wanting to access final values of variables; that trace scripts are not guaranteed to provide access to any specific variable either was actually what I feared might be the main shortcoming of the above proc! Could the NRE atProcExit be modified to run code after the proc body but before its local context is destroyed?

AMG: What's the status of [atProcExit]?