Notes on 29 July manual

[Eric Benson <BENSON at UTAH-20>]

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
	or macros.

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
	"doesn't".

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
	self-implementation.

-------