Questions about specification and possible implementations

[Skef Wholey <Wholey@CMU-CS-C.ARPA>]

    Date: Thursday, 4 October 1984  19:01-EDT
    From: JonL.pa at XEROX.ARPA

    Hmmm, I think this discussion is beating around an important "bush" --
    namely *exactly* which of the functions in the Common Lisp spec is it
    permissible to open-code in such a way that TRACE, BREAK, ADVISE, etc
    will not work?

(DECLARE (NOTINLINE FOO)) is the way to make FOO traceable regardless of what
the compiler might do.  All implementations should grok that.

                    Additionally, there may be other functions for which
    TRACE etc cannot work (there are a number of such functions in
    Interlisp-D -- QUOTE comes to mind -- and woe betide the poor loser who
    accidentally stumbles across one, for his machine will rapidly take a
    non-returnable vacation "South")

QUOTE is a special form.  The Common Lisp specification of TRACE indicates that
it may be used to trace functions, not macros or special forms.  I agree that
tracing macros and special forms can be useful, but restricting TRACE to
functions is an elegant way to avoid that problem.  Indeed, there are some
functions that probably can't be traced, but I believe the encapsulation code
can figure out when it's being invoked recursively.  Our TRACE endeavors to do
this.  Making the encapsulation code be compiled (easy and fun with lexical
closures!) avoids the lossage that can happen when one traces EVAL, for
example.

    I see Hedrick's complaint as continuing evidence of the tension in this
    community between the special-purpose microcoded machine adherents and
    the general-purpose stock hardware men.  I'm with Chuck in thinking that
    it was a mistake to remove names of functions that are "there only for
    compiler optimizations" -- as long as Common Lisp is going to run on
    something other than a 3600 or a PERQ, more attention needs to be paid
    to these needs.  (i.e., when Chuck says "I believe it to be a mistake to
    do these optimizations", I take him to mean that either you must compile
    a call to the documented function, or else provide a documented name of
    the right functionality that the user might put in his source code).

If I were also involved in doing a stock-hardware implementation (which I am),
I don't think I'd decide to do these things differently.  I assume you meant
that this quick check could be part of a microcoded instruction.  If I
implemented the scheme I outlined in my previous message, I would do so without
introducing any new macroinstruction.  I don't think it's worth the microcode.

    At one time, all such needs were swept into the bag of "it's only a
    compiler optimization, put it in a DECLARE" -- remember the RPG Memorial
    Vector Proposal -- but if these "compiler optimizations" are critically
    essential to any realistic implementation on stock hardware . . . 

Almost all of the "compiler optimizations" that make vector hacking cheap on
stock hardware are very easy to do if the right information is around at the
right time.  Declarations are important in Common Lisp on stock hardware; if
you're implementing Common Lisp on stock hardware, your compiler should be
structured so that the information from the declarations is easily accessible
in your code generator and optimizers.

    Incidentally, your solution of dynamic testing is similar to many speed
    optimizations that compilers sometimes emit (e.g., doing an open-coded
    EQ check before actually calling EQUAL), but I'd had to see it applied
    to all those "myriads" of functions that took any keyword -- think of
    the code-size bloat!

If you're concerned about code size, do (DECLARE (OPTIMIZE SPACE)).  I've spent
a great deal of time in the past few weeks staring at assembly code listings,
and I'm pretty sure that such a test on function calls to keywordized functions
would not contribute significantly to code size.  There are "myriads" of
functions that take keyword args, but I don't think there are "myriads" of
calls to those functions.

--Skef