Re: Questions about specification and possible implementations

[JonL.pa@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?  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")

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).

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 . . . 


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!


-- JonL --