[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notes on 29 July manual
- To: Common-Lisp at SU-AI
- Subject: Notes on 29 July manual
- From: Eric Benson <BENSON at UTAH-20>
- Date: Fri, 13 Aug 1982 17:48:00 -0000
Just a few comments on the 29 July edition of the Common Lisp manual.
Some of these have already been mentioned.
p.6 SAMPLE-MACRO is shown returning the wrong value!
(sample-macro x (+ x x)) => nil
p.10 The COMPOSE example appears to use evaluation of the CAR of a form,
a la Scheme. The intended action would seem to require the use of
FUNCALL instead. Specifically, I would assume that
(defun compose (f g)
#'(lambda (x) (f (g x))))
would use the global function definitions of F and G and ignore the
parameters. The intention I believe was for
(defun compose (f g)
#'(lambda (x) (funcall f (funcall g x))))
p.18 I assume that "b" and "B" are reserved for the future addition of
bigfloats. Since Lisp code exists for bigfloats, why not
just include them in the standard?
p.33 Numbers, strings and bit-vectors are self-evaluating. Why not
everything but symbols and conses? If you want to reserve other
types for possible future extensions to EVAL, why are bit-vectors
special? Certainly characters should fall into the same category.
Why not all types except symbols, conses, (array t) and (vector t),
since those are the only types which could ever be useful in EVAL.
p.37 Since a select-expression can be used wherever a lambda-expression
is legal, you should include select-expression as a subset of
lambda-expression for the purposes of documentation. Otherwise you
will have to look for every occurrence of "lambda-expression" and make
sure it says "lambda-expression or select-expression".
p.44 Is the compiler allowed to substitute the constant value of a
defconst variable? If not, it should be made clear what the
preferred way of implementing "manifest constants" is, i.e. #.foo
p.84 The rule about AND and OR passing multiple values only from the
last form is strange. I understand the implementational reason for
it, but it's one of those rules that makes the language difficult
for novices. I would prefer to see multiple values simply
disallowed in AND and OR.
p.102 The comment on the (non) usage of the property list by the
interpreter is gratuitous. It really belongs as a suggestion in
the blue pages, not as user documentation in the white pages. Of
course it would be foolish to implement a Common Lisp interpreter
using the property list to store name strings, values or functions,
but it's no business of the language definition saying Common Lisp
p.168 The sense of ENDP is reversed, I believe. It should be true of nil
and false of conses.
p.216 It is rather unfortunate that the Common Lisp reader requires the
implementation of multiple values for what used to be splice
macros. As far as I can tell, the only way to tell how many values
are returned by a function is to make a list of them anyway (there
really should be another way, perhaps a special form like
MULTIPLE-VALUE which binds the number of values to one of the
variables). I would have thought having the read macro
tail-recursively call READ would be equally good, and it would make
bootstrapping much easier. This appears to be the only place where
multiple values would be necessary for a Common Lisp