[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bugs in the Laser Edition
- To: Common-Lisp%su-ai at USC-ECL
- Subject: Bugs in the Laser Edition
- From: BENSON at SPA-NIMBUS
- Date: Thu, 28 Apr 1983 20:42:00 -0000
- Mail-from: ARPANET site SU-AI rcvd at 28-Apr-83 1659-PDT
Here are some minor bugs (and fixes) from the Laser Edition. Most of
these are just internal inconsistencies or things that should have been
flushed from previous editions. There is also a serious problem which I
am preparing a note about, which will require some significant changes
(there is no easy way around it). This relates to what is legal as the
first argument to FUNCALL or APPLY, what SYMBOL-FUNCTION returns, etc.
I think it will be necessary to be more explicit about what lexical
environments are, rather than the hand-waving "implementation dependent"
copout.
-- Chapter 3, p.28
The program example
(DEFUN COMPOSE (F G)
#'(LAMBDA (X) (F (G X))))
should be changed to
(DEFUN COMPOSE (F G)
#'(LAMBDA (X) (FUNCALL F (FUNCALL G X))))
(The author apparently thought he was writing an example of Scheme!)
-- Chapter 3, p.29
The term "exit point" needs some clarification. The sentence
An exit point established by a BLOCK (page 79) construct has lexical
scope and dynamic extent.
could be changed to
An exit point established by a BLOCK (page 79) construct and referenced
by RETURN (page 79) or RETURN-FROM (page 79) has lexical scope and
dynamic extent.
-- Section 5.3.3, p.49
The word "situation" in the first line of the description of EVAL-WHEN
should be in italics, not Helvetica.
-- Section 6.4, pp.58,59; Section 7.6, p.77
The special forms AND, OR and IF are defined in terms of COND. This may
be considered inappropriate since COND has now been defined to be a
macro rather than a special form. It might be more appropriate to
define COND, AND and OR in terms of IF.
-- Section 7.1.2, p.65
FSET should be flushed with all the other update functions, in favor of
(SETF (SYMBOL-FUNCTION x) y). The word FSET could easily be confused
with SETF.
-- Section 7.10, p.93
CATCH-ALL is sometimes spelled CATCHALL in its description.
-- Section 9.2, p.103
It should be mentioned in the description of the SPECIAL declaration
form that DEFVAR is the recommended way of declaring a special variable.
-- Section 10.1, p.109
PUTF should be flushed, since (SETF (GETF x y) z) works equally well.
-- Chapter 16, p.189
All references to PUTHASH in the introduction to this chapter should be
changed to (SETF (GETHASH x y) z). PUTHASH has already been flushed.
-- Section 17.2, p.195
There is a reference to STRING<> in the description of STRING-NOT-EQUAL,
which should be changed to STRING/=.
-- Section 18.5, p.207; Section 21.1.6, p.241
The DEFSTRUCT description refers to a :PRINT-FUNCTION option, while the
PRINT description refers to a :PRINTER option for DESTRUCT. One of
these should be changed to the other. It should be stated in both
sections what the default printed representation of a structure is, if
this option is not specified. There should be a way to specify the
#S(...) reader macro syntax as the printed representation without having
to "do it by hand."
-- Section 21.3.1, p.248
A minor point: PPRINT probably should not return its argument, in order
to be useful when called from a READ-EVAL-PRINT loop. Otherwise the
prettyprinted form tends to get scrolled off the screen by the
"standard" printed return value. This recommendation is made on the
basis of practical experience! Have it return T or NIL or some other
benign object instead.
-- Section 24.1, p.289
In the first paragraph of the description of the COMPILE function, the
term "lambda expression or select expression" is used. This should be
changed to just "lambda expression," since select expressions have been
flushed.