This compiler has a feature which is not found in many LISP compilers. It is possible to order the compiler to generate a code for the user defined and compiled LISP functions, such that they (or a subset of them) will be redefinable at run-time. Furthermore it is also possible to have a code generation that enables tracing of compiled user defined functions.
If you are performing a LISP C compilation then you have the choice to set the flag !*traceable to a non-nil value (by default it is nil) before you start the compilation with the compilefile function. If !*traceable is set then the C code generation of all user defined functions is altered to have an overhead code that performs a check on the global environment (which is set by the LISP function traceable , and described below), and if this environment says at that moment a trace is desired a trace-print out will be done. The code change that is done when !*traceable is non-nil, is performed by an insertion of a C macro. Now if TRACEABLE, a C define macro in the flags.l file, is set to zero then the C compiler will omit this inserted overhead. But if TRACEABLE is set to 1 then the compilation will be done so that the user defined functions are traceable. Therefore, it is always clever to perform the LISP C compilation with !*traceable set to non-nil and then use or not this code alternation by controlling the C define macro TRACEABLE in the flags.l file.
Similar to !*traceable you can set the flag !*rdable which will generate a C code for user-defined functions that allows them to be redefined at run time in such a manner that even the compiled functions will use this new definition. ( Normally, for most of the LISPs this is not the case, of course it is trivial that in any LISP you can redefined a compiled function, even you can replace a new definition for car but this will only effect the interpretive calls to that function and not the calls inside the compiled code, that means if you have compiled two functions A and B and A is calling B then you redefine B at runtime, from that moment on all interpretive calls to B will use the new definition but A will still work in the old fashion, making use of the old definition of B \).
If you have set !*traceable this automatically implies all the user defined functions to be redefinable, so you do not have to set !*rdable in addition.
Although it is not possible to define a subset of functions to be traceable it is not so for `redefinability'. It is possible to declare a set of functions to be redefinable. This is done by flagging their names with the atom rdable, prior to compilation (i.e. issuing the compilefile call).
At run time the control of tracing and redefinition is done by the function traceable. The usage follows:
Redefinable or traceable code has some computational overhead, that is for sure. But when the use of the redefinitions is enabled an extensive check and process is performed, it could be the case that although you have compiled with redefinition ability, you don't want to use it at that instance, or you do not want to trace, in those cases it is desirable to issue (traceable nil) which will minimize the computational overhead (in this case on a conditional on a global variable will be processed).