Re: Questions about specification and possible implementations

[JonL.pa@XEROX.ARPA]

NOTINLINE isn't the issue -- it's knowing *who* needs to be so protected
when one wants to ensure traceability.  In fact, many major Interlisp-D
operations are ambiguous at the compiler level -- the compiler merely
emits an opcode with *may or may not* call the function of the
corresponding name.

I agree -- it's too bad that special forms and macros aren't traceable.
But as you recognize, that isn't the source of the unTRACEability
problem -- it's when the encapsulation function somehow depends on the
function being traced.  If encapsulation functions were always compiled
(by possibly a super-fast non-optimizing compiler) then the space of
untraceables would diminish dramatically.  PDP10 MacLisp tried to do
something like that -- using "hidden" copies of the systems functions
which it used (like PRINT ...).  Unfortunately it, like Interlisp,
didn't "hide" QUOTE.

Re the space cost of "double-compilation" (may I call the scheme you
proposed that? the one to emit both code sequences for open and for
closed formats, which is toggled by a runtime switch), and you comment
". . . but I don't think there are 'myriads' of calls to those
functions".  Did you examine the SpiceLisp implementation, or user
application programs?

-- JonL --