[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions about specification and possible implementations
- To: Rem@IMSSS
- Subject: Questions about specification and possible implementations
- From: Moon@SCRC-RIVERSIDE.ARPA
- Date: Mon, 24 Sep 84 16:55 EDT
- Cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA
- In-reply-to: The message of 23 Sep 84 20:52-EDT from Rem at IMSSS
- Redistributed-date: Mon, 1 Oct 84 14:20 EDT
- Redistributed-date: Thu, 27 Sep 84 23:49 EDT
- Redistributed-to: COMMON-LISP%SU-AI@SU-SCORE.ARPA
- Redistributed-to: COMMON-LISP%SU-AI@SU-SCORE.ARPA
Date: 23 Sep 1984 1752-PDT
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
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
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
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.
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.
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.