Questions about specification and possible implementations

[Moon@SCRC-RIVERSIDE.ARPA]

    Date: 23 Sep 1984 1752-PDT
    From: Rem@IMSSS

    In Common LISP there seems to be a strong dichotomy between functions
    (all arguments evaluated before call) and macros&SpecialForms, almost
    to the point of forbidding implementors to jump across the barrier.
    Yet some functions with all the &OPTIONAL and &KEY arguments may be
    difficult or inefficient to implement as true functions, and thus may
    be implemented as FEXPRs in the interpretor and MACROs in the
    compiler.

It is impermissible for an implementation to implement something documented
as a function as something other than a function.  This doesn't rule out
compiler optimizations, of course, and all the implementations I know about
do compiler optimizations for the hairier and most common functions with
&KEY arguments.

    The book says the set of special forms is fixed and no way is provided
    to make new ones. But is any way provided to define some of the
    special forms from LISP level in the first place, or must all be
    handcoded in assembly language or C etc.? Is any way provided to
    install bugfixes in special forms by overlaying the old definition
    with a new one?

This is an issue for each implementation to address.  The Common Lisp language
is a portable subset, not a complete implementation.  To take one example, in
our implementation the interpreter routines for all of the special forms are
defined in Lisp, using a special-form-defining-special-form that you won't find
in the Common Lisp manual.

The reason it would be inutile to provide a portable way to define special forms
is that they have to be defined for both the interpreter and the compiler.
While it's (almost) easy to define portable extensions to the interpreter, there
is a wide variation in compiler techniques.  Trying to standardize this would be
a monumental task, and probably doomed anyway since compiler techniques are
often dictated by the underlying hardware.

    At the front of the chapter on numbers it claims:
     (LET ((X Z) (Y Z))
       (EQ X Y))
    may be false if the value of Z is a number. I can't see a mechanism
    for this in any reasonable LISP unless Z is not only presently a
    number but has been declared a number and this is compiled code which
    represents the value of Z as a machine number instead of a LISP
    object, whereas X and Y are undeclared and thus LISP objects, so new
    objects must be constructed for X and Y to hold the value Z, and these
    new objects won't be EQ to each other. But could somebody who really
    knows tell me what the true explanation is?? The book leaves this a
    complete mystery.

Try the following example in pdp10 Maclisp (compiled without declarations).
	
	(defun tst (z)
	  (let ((x z) (y z))
	    (eq x y)))
	
	(defun tst2 (a b)
	  (tst (+ a b)))

	(tst2 1234567 -1) => nil

I don't think the book needs to explain the inner workings of this.  Common Lisp,
as a portable subset language, is allowed to contain freedoms for implementors
even if no current implementors exploit those freedoms, if it's reasonable to
assume that in the future someone may need those freedoms.

    Minor questions:

    In the introductory chapter, the Common-LISP book says semicolon
    causes all characters up to eol to be discarded, but doesn't say
    whether eol is kept or discarded.

A comment is equivalent to whitespace.  In Lisp syntax it doesn't matter
whether whitespace is made out of spaces, carriage returns, or something
else, it just serves to separate tokens.

    Ditto, doesn't say which characters inside "" are automatically
    letterified and which have their usual semantic effects and thus need
    explicit letterification to be treated as string text.

Huh?

    Ditto, backslash at end of line does what? (Illegal, quote just the
    next character which may be half of a crlf on some systems, quote the
    eol token always?)

This is a good issue.  From the discussion on page 22 I think it is supposed to
give a Newline character.

Bug in the manual: the word "newline" does not appear in the index.

    Ditto, vertical-bar, same questions as for "".

    (If above questions are answered elsewhere in manual, need pointer
    from intro to where info given?)

    When COPY-SYMBOL is done, the pnames will be the same, but will they
    be EQ or just EQUAL?

Presumably this should be undefined since there is little to be gained by
defining it one way or the other and an implementation might want to do
something strange.  After all, it is not even defined whether calling
SYMBOL-NAME twice on the -same- symbol yields EQ values!

    The book doesn't say what (/ 1 0) does. Is it an error, or does it
    signal an error, or does it return the ratio of 1/0 as a way of
    representing infinity, or what?

Good question.  There are no infinities in the standard numbers of Common Lisp,
so it can't be required to return 1/0.  My guess is that Common Lisp does not
rule out a particular implementation deciding to return 1/0.  In other words
it "is an error" -- portable programs should not depend on what happens, and
different implementations might do different things.

    If NIL is an element of an assoc list, does this element get skipped
    over by ASSOC et al or is it a stop flag?

Second to last paragraph on page 279.

    How are the axis numbers of an array numbered, that is if you
    create an array by (MAKE-ARRAY 3 5 7) then will (ARRAY-DIMENSION array 0)
    return 3 or 7?

Good point.  It returns 3, but I don't see anything that says that explicitly.