Study alternatives to use of auto_index for on-demand compilation
andreas-kupries opened this issue · comments
In mode compile&run
Critcl currently populates the auto_index
array with the declared commands, so that the standard unknown
can trigger the compilation on first use.
Proposed alternatives:
- rkeene : Create Tcl shims which trigger compilation and get replaced with the compilation result.
- dgp : Hook into
namespace unknown
.
Study feasibility of either.
For background, there is some intent and pressure on the core to remove auto_index
.
A first thing to do would be to isolate the code doing the registration (if it is not already).
Then it can be replaced with alternate implementations.
Thoughts:
- The idea of shims is likely the most portable not depending on any specific version of the core, and its features. I.e.
namespace unknown
is a recent feature we would have to check for before using it. - The current code is portable across major versions simply because
auto_index
exists since pretty much the beginning. That breaks shouldauto_index
go away. Plain Tclproc
s on the other hand will never go away.
I added the shim proc in tcc4tcl's basic critcl wrapper here: http://chiselapp.com/user/rkeene/repository/tcc4tcl/artifact?ln=68-85&name=f455727caf579fa7
And it seems to work
Thank you. Copied into here
68 proc ::critcl::cproc {command argList resultType body} {
69 set handle [::critcl::_allocateHandle]
71 set command [::tcc4tcl::lookupNamespace $command]
73 $handle cproc $command $argList $resultType $body
75 set body {
76 set args [uplevel 1 set args]
78 ::critcl::_go $handle
81 tailcall $command {*}$args
82 }
84 proc $command args [list apply [list {handle command} $body] $handle $command]
85 }
Regular critcl
might be able to work without apply
, and tailcall
conditionally (8.6+), uplevel
otherwise.