Questions about specification and possible implementations

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

You say that it's OK to open code some functions, like CAR and SVREF.

You say that it's not OK to do something like code a call to Write-Line with
:start and :end arguments as a call to some internal Keywordless-Write-Line to
avoid consing a rest argument.

Is it OK to open-code a function some times (e.g. when we know that the
sequence argument to Position is a simple-string and we know that the item
being searched for is a string-char, we could use the Vax SCANC instruction),
but not others?  Is that "too complicated a function"?  Realize that no one is
going to use those generic sequence functions if they always cons rest args and
parse keywords at runtime.  I consider it an implementor's duty to try to
eliminate at least some of that runtime penalty.

What about "fast function calls?"  Is it alright for an implementor to compile
his Lisp-level code in such a way that when system code calls Print the call is
untracable?  Is it alright for the writer of a "module" to do so?  Why should
the random user who wants to trace Print have any reason to believe that the
writer of the code supplied to him used that function?  Sounds like
information-hiding to me.  Last I checked, that was suppsoed to be a good
thing.

The only difference here seems to be what you might consider reasonable
things to open-code based on your knowledge about implementing Lisp.  That's
going to vary a whole lot from machine to machine.

Partition the set of Common Lisp functions into three classes:
     1. Those that may be open-coded.
     2. Those that may either be open-coded or left alone.
     3. Those that should never be open-coded.
Can you?  Should you?  Were you the one complaining about Common Lisp
discriminating against stock hardware?  The sorts of optimizations I want to do
(and as a user, want done for me) can only help the performance on stock
hardware.  If it were ruled that it was absolutely not permissable to cleverly
code any keyword-taking functions, "we" microcoded-machine people would just go
off and write some fast keyword-parsing microcode.  What would the Vax and 20
people be left doing?

Remember that as a last resort, good old DISASSEMBLE is there.  There IS a way
for the user to peer into compiled code to see what's really happening.
Information-hiding is a good thing, but a better thing about Lisp is that it
has usually provided a way around it, so that people can get work done.  I've
used the Lisp Machine Inspector to "unlock" a package to hack some symbols in
that package.  I didn't need to read any documentation or source code.

There's no real reason to treat compiled code as a black box and TRACE as
the only tool for finding things out about the contents of that box.  Contrary
to what Hedrick says, this IS Lisp.

--Skef