[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Kim Barrett's comments on the 8/29/89 draft
[This message is really from Kim Barrett but he doesn't have network access right now. -kmp]
Comments on the 8/29/89 draft, as of 1/5/90, by Kim A. Barrett
==============================================================================
General Comments
1. The fonts being used are almost unreadably small. The specialized fonts
chosen for various highlighting are often impossible to differentiate. I
think we really ought to up the font size a bit, even though doing so will
increase the page count. It might be that a higher quality print would make
the current fonts ok. I tried to compare CLtL with the draft, and the font
sizes look comparable (though I don't have a micrometer handy to do a really
accurate check). CLtL is readable because the printing is much crisper than
the draft standard.
2. I think there ought to be another level of section numbers, rather than
only having two numbered levels, with additional subsections not numbered.
For example:
2.2.1 Data Type Definition
2.2.2 Type Hierarchy Diagrams
2.2.3 Type Relationships
&etc
3. As a general rule, any place which says a condition is or should be
signaled should specify the type of condition. Also, it should never be
required that the condition being signaled be a subtype of SIMPLE-CONDITION.
That is, never require signaling a SIMPLE-ERROR. Instead require signaling
an ERROR. (The only place I know of right now that does this is ASSERT.)
==============================================================================
Chapter 2, Types and Objects
Section 2.1, Introduction
1. The second paragraph talks about declarations, and states that global
declarations are established with PROCLAIM. It fails to mention the new
macro DECLAIM.
2. The last line of the second paragraph, which says
"but an implementation is not required to detect such conditions"
is redundent with the definition of undefined consequences, and should be
removed.
Section 2.2, Types
1. Do figures 2-2, 2-3, and 2-4 really serve any useful purpose here, or are
they just taking up space?
2. Aren't atomic type specifiers defined names? Shouldn't the descriptions of
all these types be moved to chapter 6 and put in alphabetical order? If that
doesn't happen, then there are some inconsistencies in the order in which
types are introduced. In general this section introduces a type only after
its supertypes have been described. However, this isn't always done, and
there are a couple of places where that would be a bit awkward. I'm not going
to make any further comments on this problem though, on the assumption that
these descriptions will be moved to chapter 6.
3. As a general rule, where the subtype relationships are specified, they
ought to be in class-precedence-list order. Most entries follow this (with
some interpolations where the cpl's for the predefined classes are
insufficient to determine it), but there are inconsistencies. I will note
them where I find them.
4. Most of the description of the type NUMBER should be removed. There is no
need to mention the subtypes of REAL here (that gets taken care of by the
description of REAL), nor is there any need to say that EQL and = may treat
(some) numbers differently than EQ need to be here (this should be taken care
of by the descriptions of these functions).
5. In the description of COMPLEX, explicitely state the canonicalization rules
for complex numbers, rather than the less precise language used here. If the
real part and the imaginary part are of different types, then the contagion
rules are applied to the values. If, after contagion, the real part is
rational and the imaginary part is zero (must be rational, due to contagion),
then the result is actually just the real part.
6. The description of the type RATIONAL contains a better description of the
type RATIO than is given under RATIO. Move the description to RATIO and
change RATIONAL to reference RATIO.
*** 7. characters
8. In the description of EXTENDED-CHARACTER, note that in implementations
where the type BASE-CHARACTER is equivelent to the type CHARACTER, the type
EXTENDED-CHARACTER is equivelent to the type NIL.
9. When describing the property list component of SYMBOLs, it states that
"All indicators on a property list must be distinct from one another."
The word "distinct" means "not EQ", but that may not be understood.
10. In the last sentence of the description of SYMBOL, there is a case
mismatch: "A symbols can also have ...". Either drop the leading "A" or
make "symbols" singular.
11. The description of the type LIST is confusing. A simpler description
would make use of LIST = (OR CONS NULL) and then talk about the distinction
between true and dotted lists.
*** 12. Look at the description of SIMPLE-ARRAY in light of
ADJUST-ARRAY-NOT-ADJUSTABLE mess.
13. The subtype ordering of the various vector types does not follow
class precedence list ordering. In particular, the subtype orderings
should be:
VECTOR ARRAY, SEQUENCE, and T
SIMPLE-VECTOR VECTOR, SIMPLE-ARRAY, ARRAY, SEQUENCE, and T
BIT-VECTOR VECTOR, ARRAY, SEQUENCE, and T
SIMPLE-BIT-VECTOR BIT-VECTOR, VECTOR, SIMPLE-ARRAY, ARRAY, SEQUENCE, and T
STRING VECTOR, ARRAY, SEQUENCE, and T
SIMPLE-STRING STRING, VECTOR, SIMPLE-ARRAY, ARRAY, SEQUENCE, and T
BASE-STRING STRING, VECTOR, ARRAY, SEQUENCE, and T
SIMPLE-BASE-STRING BASE-STRING, SIMPLE-STRING, STRING, VECTOR, SIMPLE-ARRAY,
ARRAY, SEQUENCE, and T
Note that I have added SIMPLE-STRING to the supertypes of SIMPLE-BASE-STRING,
inserting it between BASE-STRING and STRING.
14. A better way to describe BIT-VECTOR is to say that it is "a vector
specialized to hold bits", rather than "a vector composed of bits".
15. For FUNCTION, it says
"A FUNCTION can be supplied as an argument without error to FUNCALL or
APPLY, ..."
This isn't necessarily right. Being of type function may only imply that
FUNCALL and APPLY won't complain about a type error, but may still do
argument quantity checking. But perhaps some peoply think that argument
quantity checking is done by the function being called, rather than by
the function calling mechanism. Where to draw the line is sufficiently
fuzzy that I would probably disagree with such claims.
16. Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN (Version 7) says that
COMPILE returns an object of type COMPILED-FUNCTION. This information should
be added to the description of the type COMPILED-FUNCTION.
17. The supertypes of STANDARD-GENERIC-FUNCTION (in class precedence list
order) probably ought to be GENERIC-FUNCTION, FUNCTION, and T. Currently it
has FUNCTION before GENERIC-FUNCTION.
18. In the description of CONDITION, the text from issue CLOS-CONDITIONS
stating that all types of conditions are classes seems misplaced here. This
belongs in the section called "Type Relationships" (see comment below). The
statement that "all condition objects are instances of one or more classes"
should just be stricken. This is pretty much a meaningless noise, since all
objects are instances of one or more classes.
19. The descriptions of the various condition types often make reference to
slots, in a way which seems to imply particular names to those slots. For
example, the description of the various subtypes of SIMPLE-CONDITION include
the following statement:
"If :FORMAT-ARGUMENTS is not supplied to MAKE-CONDITION, the
FORMAT-ARGUMENTS slot defaults to NIL."
It is not clear in my copy of the draft whether FORMAT-ARGUMENTS is in
defined-name font or not. I don't think the names of the slots in the
standard conditions need to be specified (in fact, I'm going to propose an
ammendment to the appropriate proposal which limits what an implementation
can use defined names for). Because we now allow WITH-SLOTS (and SLOT-VALUE)
to be used to access condition slots, we need to be more careful about the
wording in these descriptions to make it clear that the only defined way to
access the slots in a standard condition is through the defined reader
functions, and that we have not specified any slot names. (See new issue
CONDITION-SLOTS.)
20. I think that SIMPLE-CONDITION is in the wrong place in the supertype lists
for those conditions which include it (SIMPLE-ERROR, SIMPLE-TYPE-ERROR, and
SIMPLE-WARNING), assuming that the supertype lists in the descriptions are in
class precedence list order. The only reason to include SIMPLE-CONDITION is
to force a particular report method (using the values of the :format-string and
:format-arguments initargs), so it should be the first included type, in order
to override any report methods defined on the other supertypes.
21. For UNBOUND-VARIABLE, I think the description is not quite right (although
it matches what was said in the Condition System proposal). I don't think
variables are unbound. Symbols may be unbound, ie. (symbol-value (gensym))
should signal an unbound variable, but I see no "variable" here, only a
symbol.
22. In UNDEFINED-FUNCTION, change "access the definition of an undefined
FUNCTION" to "access the definition of an undefined FUNCTION NAME".
23. In the description of the type RESTART, the last sentence is
"A restart has has DYNAMIC EXTENT."
which contains the word "has" twice. Also, is this even the right place to
say this? Doesn't this require talking about the extent of the form which
created the restart? Seems like this should be moved to the description of
the functions which establish restarts.
24. The description of the type CLASS says that certain things are associated
with an object of type CLASS. How much of this really MUST be true as far as
this standard is concerned (especially since we don't define any mechanism for
getting at this associated information)? I'm particularly concerned about the
part which says "information about the methods that mention the class as a
specializer". This could be taken as a requirement on implementations which
really shouldn't be made.
25. We still need the metaclass of STANDARD-GENERIC-FUNCTION.
26. Figure 2-6 has the following bugs:
1. Standard-char is a subtype of Base-character
2. Simple-base-string is a subtype of Simple-string
3. Base-string is a subtype of String
27. Figure 2-7 has the following bugs:
1. Style-warning is an additional subtype of Warning
2. Generic-function is a subtype of Function
28. Figure 2-8 has the following bugs:
1. Rename Access-error back to Cell-error
2. Unbound-slot is an additional subtype of Cell-error
3. Simple-error is an additional subtype of Error
4. Simple-error and Simple-type-error are subtypes of Simple-condition
5. Parse-error is an additional subtype of Stream-error
6. Floating-point-invalid-operation and Floating-point-inexact are addtional
subtypes of Arithmetic-error
29. There are no descriptions for the following condition types, which were
added at the 11/89 meeting: FLOATING-POINT-INEXACT,
FLOATING-POINT-INVALID-OPERATION, and PARSE-ERROR.
PARSE-ERROR -- The type PARSE-ERROR is a subtype of the types STREAM-ERROR,
ERROR, SERIOUS-CONDITION, CONDITION, and T. The type PARSE-ERROR consists
of serious conditions that relate to lexical analysis (the building and
interpretation of tokens) and parsing. When errors of this type are
detected by the Lisp reader, conditions of this type are signaled.
FLOATING-POINT-INEXACT -- The type FLOATING-POINT-INEXACT is a subtype of
the types ARITHMETIC-ERROR, ERROR, SERIOUS-CONDITION, CONDITION, and T.
{ Figure out a description from IEEE-754. }
FLOATING-POINT-INVALID-OPERATION -- The type
FLOATING-POINT-INVALID-OPERATION is a subtype of the types ARITHMETIC-ERROR,
ERROR, SERIOUS-CONDITION, CONDITION, and T. { Figure out a description from
IEEE-754. }
30. There are no descriptions for the following atomic type names: ATOM, BIT,
KEYWORD, SIGNED-BYTE, STANDARD, and UNSIGNED-BYTE. Below are possible
descriptions for some of these.
ATOM -- The type ATOM is a subtype of the type T. All objects which are not
of type CONS are of type ATOM. The type ATOM is equivelent to the type
(NOT CONS). { Note that the addition of the type ATOM requires that ATOM be
added to the supertype lists for every type except ATOM, CONS, LIST, SEQUENCE,
and T, immediately preceding T. }
KEYWORD -- The type KEYWORD is a subtype of the types SYMBOL, ATOM, and T.
The type KEYWORD consists of those symbols whose home package is the package
named KEYWORD.
STANDARD -- { This is precisely equivelent to STANDARD-CHAR. It was added
by Character proposal 2.2.1. I've written a cleanup proposal to flush it.}
The descriptions of BIT, SIGNED-BYTE, and UNSIGNED-BYTE are a bit harder.
Exactly what is the relationship between SIGNED-BYTE and INTEGER? That is,
what is the order in which they should appear in a class precedence list? In
these descriptions I have arbitrarily put SIGNED-BYTE before INTEGER. Should
we also add SIGNED-BYTE to the supertypes of FIXNUM and BIGNUM?
BIT -- The type BIT is a subtype of the types FIXNUM, UNSIGNED-BYTE,
SIGNED-BYTE, INTEGER, RATIONAL, REAL, NUMBER, and T. The only objects of
type BIT are the integers 0 and 1. The type BIT is equivelent to the type
(INTEGER 0 1).
SIGNED-BYTE -- The type SIGNED-BYTE is a subtype of the types INTEGER,
RATIONAL, REAL, NUMBER, and T. This is a type which abbreviates. The type
(SIGNED-BYTE n) consists of the set of integers which can be represented in
two's-complement form in a byte of n bits. It is equivelent to the type
(INTEGER -2â??(n-1) 2â??(n-1)-1). The types SIGNED-BYTE and (SIGNED-BYTE *)
are equivelent to the type INTEGER.
UNSIGNED-BYTE -- The type UNSIGNED-BYTE is a subtype of the types
SIGNED-BYTE, INTEGER, RATIONAL, REAL, NUMBER, and T. This is a type which
abbreviates. The type (UNSIGNED-BYTE n) consists of the set of non-negative
integers which can be represented in two's-complement form in a byte of n
bits. It is equivelent to the type (INTEGER 0 2â??n-1). The types
UNSIGNED-BYTE and (UNSIGNED-BYTE *) are equivelent to the type (INTEGER 0 *).
31. In the section titled "Type Relationships", many of the bullets seem
unnecessary given the information already given about the specific types and
some of the preceding bullets. The following bullets can be removed.
* The type NIL is a subtype of every type whatsoever. No object is of type
NIL. { Follows from description. }
* The types SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, and LONG-FLOAT are
subtypes of type FLOAT. Any two of them must be either disjoint or
identical; if identical, then any other types between them in the above
ordering must also be identical to them (for example, if type SINGLE-FLOAT
and type LONG-FLOAT are identical, then type DOUBLE-FLOAT must be identical
to them also). { Follows from description. }
* The type NULL is a subtype of SYMBOL; the only object of type NULL is NIL.
{ Follows from description. }
* The type STANDARD-CHAR is a subtype of type CHARACTER. { Follows from
description. }
* The type STRING is a subtype of type VECTOR. { Follows from description. }
* The type BIT-VECTOR is a subtype of type VECTOR, for BIT-VECTOR means
(VECTOR BIT). { Follows from description. }
* The type VECTOR is a subtype of type ARRAY; for all types x, (VECTOR x)
is the same as (ARRAY x (*)). { Follows from description. }
* The type SIMPLE-ARRAY is a subtype of type ARRAY. { Follows from
description. }
* The type SIMPLE-VECTOR is a subtype of type VECTOR, and is a subtype of
type (VECTOR T). { Follows from description. }
* The type SIMPLE-STRING is a subtype of type STRING. { Follows from
description. }
* The type SIMPLE-BIT-VECTOR is a subtype of type BIT-VECTOR. { Follows from
description. }
* The type VECTOR and LIST are disjoint subtypes of type SEQUENCE. { This
follows from earlier disjointness requirement (bullet 3) plus description
of LIST (bullet 10 says CONS and NUL form an exhaustive partition of
LIST). }
* The types SIMPLE-CONDITION, WARNING, and SERIOUS-CONDITION are pairwise
disjoint. { Follows from augmented bullet 3 (see below). }
* Any two types created by DEFSTRUCT are disjoint unless one is a supertype
of the other by virtue of the DEFSTRUCT :include option. { Follows from
bullet 3. }
* Any two classes created by DEFCLASS are disjoint unless they have a common
superclass or one class is a superclass of the other. { The part of this
which is correct follows from bullet 3. The stuff about common
superclasses is bogus. }
32. Bullet 3 of the Type Relationships section fails to mention
DEFINE-CONDITION as a form which creates types. DEFINE-CONDITION should
have the same sort of words as DEFCLASS. Note that DEFINE-CONDITION
always creates subtypes of CONDITION, which is mentioned earlier in the
list, so some care may be needed to clean this up. Also, some care in the
wording may be needed to allow implementations to define conditions using one
of the standard metaclasses without violating the disjointness constraints.
33. Expand the description of the type T to include the information in
bullet 1 of the Type Relationships section, and flush that bullet.
34. The paragraph describing type specifiers omits DEFINE-CONDITION as a way
to define new types.
35. The bullet which says
"The types CONS and NULL form an exhaustive partition of the type LIST."
could be moved to the description of the type LIST and flushed from the
section on Type Relationships.
36. Figure 2-10, Syntax for Type Specifiers, contains the following bugs:
1. The specified syntax for MEMBER, AND, and OR all require the list to
be of length at least 2. I don't believe this follows from the
descriptions in CLtL. All of these are well defined for a list of
length 1:
type (MEMBER) == type NIL
type (AND) == type T
type (OR) == type NIL
2. (VALUES val-ts) should probably be done using the downarrow indirection
indicator described in Chapter 6 as a BNF extension used in the
descriptions of the defined names.
37. Figure 2-11, Table of Atomic Type Specifiers, has CELL-ERROR misnamed
ACCESS-ERROR, and is missing FLOATING-POINT-INEXACT (new),
FLOATING-POINT-INVALID-OPERATION (new), GENERIC-FUNCTION, PARSE-ERROR (new),
STANDARD (hopefully going away), STANDARD-GENERIC-FUNCTION, and STYLE-WARNING.
It also is not properly alphabetized.
38. There isn't any equivelent to CLtL sections 4.2 through 4.6, which means
that we haven't said what most of the list form type specifiers mean!
Probably this needs to be done within the descriptions of each of the type
specifiers. However, this has not been done. We've basically dropped about
8 pages of CLtL here.
39. The title of the "Type Relationships" section has the word relationships
uncapitalized.
40. The description of STRUCTURE-OBJECT should have some words similar to
what what the description of STANDARD-OBJECT says, ie
"The class STRUCTURE-OBJECT is an instance of the class STRUCTURE-CLASS and
is a superclass of every class that is an instance of STRUCTURE-CLASS
except itself."
==============================================================================
Chapter 3, Syntax
Section 3.1, Character Syntax
1. The second paragraph, taken from Character Proposal 2.2.1, talks about
the standard character subrepertoire. Why is this a subrepertoire rather
than a repertoire? Also, the Character proposal requires that STANDARD be a
defined name, but the text here does not make that clear. Note that I am
submitting a cleanup proposal regarding the name of the STANDARD character
repertoire.
2. In Figure 3-1, Standard Character Subrepertoire, there isn't a glyph for
SM05, the "commercial at" character. Also, the footer line with the page
number in it ended up inside the figure.
3. There doesn't seem to be any discussion of semi-standard characters.
However, the semi-standard characters Backspace, Linefeed, Page, Return,
Rubout, and Tab all appear in Figures 3-2 and 3-3, the titles of which imply
that they are talking only about standard characters. There should be some
discussion of semi-standard characters, since Character Proposal 2.2.2 (which
proposed removing all discussion of semi-standard characters) failed (3/89).
{ Actually, there is some discussion in the section on macro characters, but
that seems rather far from here, where they ought to be introduced. }
Section 3.3, Interpretation of Tokens
1. The description of the valid syntax for numbers contains a section for
Complex numbers which simply describes the data type, and has nothing to do
with the syntax of the printed representation. This section should just be
removed, since the printed representation of complex numbers is not as a
single token.
Subsection Symbols as Tokens (which is improperly capitalized in the draft)
2. It says that an error of type PROGRAM-ERROR is signaled when a token
consisting entirely of dots is encountered (except in one special
circumstance). This should probably be changed to the newly added PARSE-ERROR.
3. The sentence
"In all other cases, the token is construed to be the name of a symbols."
is redundent and can be removed.
4. It says
"A symbol can have characters from any supported character repertoire
(except control characters) in its print name."
What is a control character, and why are the not permitted in symbol names?
The proposal this is supposed to be from (Character Proposal 2.6.2) actually
says to clarify that a symbol may have any character in its print name,
without any qualifications regarding these undefined control characters.
5. In the text following Figure 3-9, there is a paragraph which contains a lot
of words which basically describe the behavior of INTERN. I know rpg was
eliminating verbification of function names, but if this is the result then
I think it is a serious mistake to do so. Besides which, it says nothing
about package qualifiers (only talking about the current package), so it is in
fact pretty bogus. The presentation of package qualifiers seems to be in the
wrong place, and not well explained. In rule 1 concerning package markers, it
talks about setting the symbol-value of the symbol so that it self evaluates.
Again, this is part of INTERN, and may not even be how the implementation
produces the effect of keywords being self-evaluating. I think this whole
section needs to be rewritten.
Section 3.4, Standard Macro Characters
1. Figure 3-12, Standard # Dispatching Macro Character Syntax, contains
semi-standard characters too. What do we mean by "Standard" in the title?
2. On page 3-24, at the end of the description of the #\ reader macro, there
is some text (supposedly from Character Proposal 2.2.1) which consists of just
"xe". Seems like maybe something got lost here?
3. There appear to be some character names in the wrong font, though it is
hard to tell for certain (the fonts being hard to distinguish). Specifically,
on page 3-24, the name "rubout" seems to be in the wrong font, and similaryly
for the name "linefeed" on page 3-25.
==============================================================================
Chapter 4, Evaluation and Compilation
1. In general, when talking about macro expansion (whether normal,
symbol-macro, or compiler macro), talk about the expansion occuring with
respect to the "current syntactic environment", rather than the "current
lexical environment (or with the current compilation environment, if the
form is being processed by COMPILE-FILE)". Add a definition for syntactic
environment to the glossary.
2. The handling of errors in argument quantity and unmatched keywords is
generally inconsistent. Depending on where you look and the specific kind
of error being discussed, these can be any of "is signaled", "should signal",
or "consequences undefined". This inconsistency was discussed at the 11/89
meeting, but I don't remember if we resolved anything. It should be
consistent, and should probably be either "consequences undefined" or "should
signal". Note that if we agree on "should signal" then DEFGENERIC probably
needs to be extended to allow the SAFETY optimize quality in the declaration
option.
Section 4.1, Evaluation
1. For Self-evaluating forms, get rid of all the special cases mentioned, and
just say that a form that is not a cons or a symbol is self evaluating. The
additional stuff is not a complete set of all the exceptions and just confuses
the issue.
2. Is it necessary to keep singling out T and Nil specially, rather than just
saying that they are named constants? Keywords also sometimes get this
treatment.
3. In the description of Lexical variables, it says
"... or the binding is shadowed by a construct that creates a dynamic binding
of the same name ..."
I can't find any definition for what is meant by "shadow" here. Without the
proper definition someone might wonder if PROGV might induce the shadowing
being discussed in the quoted text.
4. The third bullet describing when a variable is dynamic may be wrong. I
was under the impression that we tried to leave undeclared free references
unspecified. Forcing them to be dynamic might inhibit experimentation with
global lexical environments. (I know we didn't pass the proposal regarding
global lexical variables, but I don't believe the intent was to completely
shut the door on them.) *** Look for supporting evidence for this claim. ***
5. When describing Global variables, don't talk about its SYMBOL-VALUE cell.
There's no such beast.
6. When talking about named constants, it says that
"An error of type ERROR should be signaled if an attempt is make to assign
a value to, or create a binding for a constant."
I am not aware of any proposal that makes this a "should signal" situation.
CLtL says this "is an error", which means the consequences are undefined. The
only passed proposal I can find which has any bearing on this is is
DEFCONSTANT-SPECIAL:DOESNT-MATTER (Version 4 passed 1/89), which says
"Clarify that it is an error to rebind constant symbols as either lexical or
special variables."
7. Figure 4-2 doesn't have LAMBDA and other forms for creating functions, all
of which establish bindings.
8. The second paragraph of the description of Conses as Forms says
"If an operator names none of these operations and the form is being
processed by EVAL, an error of type UNDEFINED-FUNCTION should be signaled."
What does being processed by EVAL have to do with this? Proposal
UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE (Version 2, passed 6/89) says
nothing about EVAL. It simply makes this a "should signal" situation.
9. Figure 4-3, Common Lisp Special Forms, still contains COMPILER-LET, which
was removed by Proposal COMPILER-LET-CONFUSION:ELIMINATE (Version 8 passed
3/89). This table needs to be checked carefully for accuracy. I have this
vague recollection of a discussion to remove GENERIC-FLET, GENERIC-FUNCTION,
GENERIC-LABELS, and WITH-ADDED-METHODS at the 11/89 meeting (at the end of the
afternoon session on the 7th, when discussing the list of questions from
Symbolics), but I can't remember whether we actually decided anything about it.
10. The section on Macros has a bunch of stuff about compiler macros. Perhaps
compiler macros should have their own section? Also, some of the stuff about
compiler macros is no longer accurate because of Version 3 of the proposal,
passed 11/89 (for example, COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1
were removed, and compiler macros can be defined on function names, not just
on symbols).
11. In the discussion of macros and compiler macros, use the term syntactic
environment.
12. The section on Macros contains the sentence
"A macro is not a function and cannot be used as a functional argument to
APPLY, FUNCALL, or MAP."
Add that this applies to other functions which take functional arguments.
State that the consequences are undefined in such a circumstance. State that
this is true if the argument is a symbol which names a macro (coercion to a
function is undefined if the symbol names a macro).
13. Figure 4-4, Defined names applicable to compiler macros and macros
contains COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1, which were removed
by Version of the proposal, passed 11/89.
14. Most of the section on Functions seems wrong. The treatment of argument
binding seems very awkward, and in some places is incorrect. In the
description of the evaluation of the arguments to the function there is the
following completely superfluous sentence:
"If any of these subforms is a symbol other than T, NIL, a keyword, or a
constant, it is a variable."
The description of the environment in which the body (and initforms) of a
function which was found by looking up the functional value of a symbol is
wrong. The evaluation environment is the lexical environment present when the
function was created, not a new environment (remember closures!).
There is a whole bunch of stuff about generic functions in this section which
doesn't need to be here. All that is needed here is that generic functions
are functions. What they do can be (and presumably is) described elsewhere.
DEFMACRO doesn't belong in the list of ways to give a global name to a
function. And the SETF method for SYMBOL-FUNCTION probably should be in the
list.
15. The relationship between global definitions (whether function or macro),
local functional definitions established by FLET, LABELS, and (if still with
us) GENERIC-FLET, GENERIC-LABELS, and WITH-ADDED-METHODS, and local macro
definitions established by MACROLET doesn't seem at all clear. Maybe there
should be a common section devoted to how to look up the "functional"
definition associated with a name, and then sections describing what to do
with each of the possible types of results.
16. Figure 4-5, Function-related defined names, should include FDEFINITION
and (if still with us) GENERIC-FUNCTION.
17. In the section on Lambda Lists it says that
"... a lambda list keyword is a symbols whose name begins with an
ampersand (&)."
This is wrong (only a convention to use symbols beginning with &). See the
constant lambda-list-keywords for a complete list (including any
implementation-specific lambda-list keywords).
What is a named argument name? This seems to be undefined.
==============================================================================
Chapter 5, Other Topics
1. Perhaps this should be broken into individual chapters, rather than all
lumped together.
Section 5.1, Errors
Subsection Condition System Concepts
1. In the description of how a handler can respond to being invoked, under
DECLINE it says that if all handlers decline then if the signaling function is
SIGNAL or WARN that the signaling function simply returns NIL; this is not
true for WARN, which first prints the warning. Under SIGNAL it says it can
signal "another" condition; this should be changed to "a" condition, since we
now allow handlers to resignal the condition they are invoked with (issue
CONDITION-RESTARTS). Also, I don't think signaling a condition is really a
method of handling. It is really just something you can do in the process
of deciding to handle. Should we even mention explicitely invoking the debugger
as an option? Note that this is potentially a serious modularity violation.
Perhaps we should even explicitely discourage this.
2. Under Creating Conditions, there are four unexplained bullets listing the
standard signaling functions and the condition type used when passed a format
string as the datum argument.
3. Figure 5-1, Condition Type Information, has a number of bugs.
1. It should not mention slots, only initarg names and reader functions.
2. Cell-error has been improperly renamed Access-Error.
3. For Type-error, the initarg name is :expected-type, not :type.
4. The types FLOATING-POINT-INEXACT (new), FLOATING-POINT-INVALID-OPERATION
(new), PARSE-ERROR (new), PRINT-NOT-READABLE, and STYLE-WARNING are
missing.
5. Unbound-slot is misnamed Unbound-slot-instance.
I think this whole table should be flushed or moved to the section on data
types in Chapter 2.
4. Under Handlers, it says
"Active handlers are established by using HANDLER-BIND or a macro based on
HANDLER-BIND, such as HANDLER-CASE or IGNORE-ERRORS."
Note that HANDLER-CASE and IGNORE-ERRORS might not actually expand into a
HANDLER-BIND. They might be defined in terms of lower level primitives.
5. Under Handlers, it says
"If the handler declines, no other handler established by that construct
will be considered for possible invocation."
This is wrong.
6. There are several places where it talks about the interactive condition
handler, talking about when it gets invoked, or stating constraints on its
behavior. These should instead be talking about the function INVOKE-DEBUGGER.
7. Under Signaling, in the 4th paragraph, it describes the behavior of ERROR,
CERROR, and SIGNAL when the condition is unhandled. It doesn't say anything
about WARN.
8. Also under Signaling, all mention of *BREAK-ON-WARNINGS* should be removed
(Proposal BREAK-ON-WARNINGS-OBSOLETE:REMOVE Version 2, passed 3/89).
9. The second paragraph of the section Restarts says that a restart contains a
function to be invoked when the restart is invoked. This is not necessarily
true, as there exist optimizations which can eliminate the need for a function
under some circumstances.
10. Under Conditions it says
"No function is provided for directly accessing, setting, or invoking
condition report functions."
This is no longer true, since CLOS-CONDITIONS specified that reporting
conditions is mediated through the PRINT-OBJECT function.
==============================================================================
Chapter 6, Catalog of Common Lisp Defined Names
Section 6.1, Introduction to Catalog of Defined Names
1. Perhaps the Notation section should be earlier in the document, so that it
can be used by earlier chapters without forward reference. For example, the
description of the syntax for the VALUES type specifier in Figure 2-10 should
be written using the downarrow indirection notation described here.
2. There is a paragraph immediately preceding the header for the section
called Operator Description Template that probably belongs within the section.
The text of the paragraph is
"The syntax description for a generic function describes the lambda-list of
the generic function itself, while the method signatures describe the
lambda-lists of the defined methods. The syntax description for a
function, macro, or special form describes its parameters."
3. In the Variable Description Template, under Description, it says
"A summary of the variable and all intended aspects of the variable, but
does not necessarily include all the fields referenced below it."
What is meant by "all the fields referenced below it"?
4. Under Numeric Operations it says that an error "should be signaled" for
logical operations on non-integers. CLtL says this "is an error". I can't
find any direction from the committee to make this a "should signal"
situation.
5. Under Numeric Operations, the third bullet says
"When a non-complex number meets a complex number ..."
This should be rewritten to not use "meets". Perhaps
"When a non-complex number is combined or compared with a complex number ..."
6. Figure 6-7, Numeric defined names -- 7, is missing the following defined
names (all introduced by FLOAT-UNDERFLOW:ADD-CONTROLS, parts 1&2 of Version 3
passed 6/89):
LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT
LEAST-NEGATIVE-NORMALIZED-LONG-FLOAT
LEAST-NEGATIVE-NORMALIZED-SHORT-FLOAT
LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT
LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT
LEAST-POSITIVE-NORMALIZED-LONG-FLOAT
LEAST-POSITIVE-NORMALIZED-SHORT-FLOAT
LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT
7. Under the section Rational Computations, why do we have the
contagion/coercion information in multiple places? And what is meant by a
"numerical" function as opposed to a "mathematical" function? These terms
are not defined, and it is necessary to know what the difference is so that
the set of functions which must return rational results when given rational
arguments (as opposed to those which might return floats) can be determined.
8. In the discussion of Complex computations, it says
"Many of the irrational and transcendental functions are multiply defined
in the complex domain; for example, there are in general an infinite
number of complex values for the logarithm function."
I think the words "in general" should be striken.
9. *** Check Figure 6-8 with the various cleanups.
10. Figure 6-24, Hash-table defined names, is missing the hash-table accessor
functions.
Section 6.2, Catalog of Defined Names
1. Add to the side effects of all the defining macros that take a
documentation string a statement that they affect the value of DOCUMENTATION
on the specified name with an appropriate second argument.
2. Ensure that the descriptions of functional arguments are consistent
everywhere, possibly by adding a section to 6.1 about functional arguments,
and then simply calling them that in the various function pages (APPLY,
FUNCALL, MULTIPLE-VALUE-CALL, MAP & friends, sequence functions, &etc).
3. Refer to implicit progn evaluation, rather than writing the description
out everywhere. There are lots of places that should be doing this but
aren't.
ADJUST-ARRAY
Generally disorganized. This is such a mess that I can't even figure out if
the latest version of ADJUST-ARRAY-NOT-ADJUSTABLE has been folded in or not,
let alone whether it has been done correctly.
APPLY
The last paragraph of the description says
"The consequences are undefined if function is a symbol that does not
have a global definition as a function, or has a global definition as a
macro or a special form."
This should be changed to strike the phrase
"does not have a global definition as a function, or"
and under Conditions, add
"An error of type UNDEFINED-FUNCTION should be signaled if function is a
symbol which does not have a global definition as a function."
This is all based on Proposal UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE
(Version 2 passed 6/89).
ASSERT
In the description of the Arguments argument, it says it can be a format
string. This should instead be format arguments.
In the Description it says
"The places should be variables on which test-form depends ..."
They should actually be generalized-variable references (see Version 18 of
the Condition System).
Why is the following section from issue SETF-MULTIPLE-STORE-VARIABLES:ALLOW
included here? Flush it.
"If a form is supplied that produces more values than there are store
variables, the extra values are ignores. If the supplied form produces
fewer values than there are store variables, the missing values are set
to NIL."
Requires that a SIMPLE-ERROR be signaled if datum is not supplied. This
ought to be just ERROR, though SIMPLE-ERROR is what the Condition System
says.
BLOCK
What does it mean to not be possible to exit from a given run-time
incarnation of a BLOCK once. I think this is an "undefined consequences"
situation which "might signal" a CONTROL-ERROR.
DECLARE
In the text taken from issue DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES, the
comments in the code talk about "should signal". However, these are not
technically "should signal" situations, since the proposal only says that
it "is an error" to violate the type declarations. Probably the easiest
fix is to change the comments to "might signal".
In the list specifying which declarations are free and which are bound,
the new declaration DYNAMIC-EXTENT is missing.
In the description of the OPTIMIZE declaration specifier, the DEBUG quality
(added by OPTIMIZE-DEBUG-INFO:NEW-QUALITY (Version 2 passed 10/88)) is
missing.
DEFCLASS
In the Arguments section, for Slot-name it says that slot-names can be any
symbol that is syntactically valid for use as a variable name. I'm not
sure what this means. Are named constants considered syntactically valid
(I think they are)? If so, then what is wrong with just saying slot names
can be any symbol? Are we trying to exclude NIL perhaps? But why?
DEFPACKAGE
Lots of missing ")" in the Syntax section.
DEFUN
In the Description it says
"Evaluating DEFUN causes function-name to be a global name for the
function specified by the lambda expression
(lambda lambda-list { declaration | documentation }* { form }*)
defined in the lexical environment in which DEFUN was executed."
I really think this is a bad way to specify this.
FUNCALL
The last paragraph of the description says
"The consequences are undefined if function is a symbol that does not
have a global definition as a function, or has a global definition as a
macro or a special form."
This should be changed to strike the phrase
"does not have a global definition as a function, or"
and under Conditions, add
"An error of type UNDEFINED-FUNCTION should be signaled if function is a
symbol which does not have a global definition as a function."
This is all based on Proposal UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE
(Version 2 passed 6/89).
GO
I seem to remember some discussion (and possibly a proposal) about the legal
go tags, with NIL being an issue. However, I can't find such a proposal.
In the description, the line
"... matching tag is contained in the TAGBODY innermost form that contains
the GO. The consequences ..."
has the words "TAGBODY" and "innermost" reversed.
{ Ensure that the discussion from EXIT-EXTENT is consistent with other
places (RETURN, RETURN-FROM, and THROW). }
LET, LET*
The description of these is not indented properly.
The syntax is currently given as
let ( { var | (var) | (var value) }* ) { declaration }* form*
let* ( { var | (var) | (var value) }* ) { declaration }* form*
This should be
let ( { var | (var [value]) }* ) { declaration }* { form }*
let* ( { var | (var [value]) }* ) { declaration }* { form }*
MACROEXPAND, MACROEXPAND-1
In the description of the Env argument, use the term syntact environment.
For the second value, change to be a boolean rather than (member t nil),
as per proposal MACROEXPAND-RETURN-VALUE (Version 1 passed 11/89).
MULTIPLE-VALUE-BIND
The third paragraph of the Description says
"The consequences are unspecified if a type declaration is specified for
a var, but the value to which that var is bound is not consistent with
the type declaration."
This is false, since the consequences are actually undefined, not
unspecified. However, this whole sentence should simply be stricken, since
it says nothing that is not understood to be the case by default.
MULTIPLE-VALUE-CALL
The first argument should be Function, not Function-Form. Its type should
be the same as the type of the function argument for APPLY and FUNCALL, ie.
(OR FUNCTION SYMBOL).
Add to the Description
"The consequences are undefined if function is a symbol that has a global
definition as a macro or a special form."
Add to Conditions
"An error of type UNDEFINED-FUNCTION should be signaled if function is a
symbol which does not have a global definition as a function."
This is based on Proposal UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE
(Version 2 passed 6/89).
PROG, PROG*
What happens with multiple EQL tags (see comment on TAGBODY).
Is NIL a legal tag (see comment on GO).
In the following paragraph of the Description, the second sentence is
unnecessary, and should be removed.
"Any declaration appearing in the PROG is used as if appearing at the top
of LET. It is an error if a declaration is supplied for a var and the
initial value of that var is not consistent with the declaration."
PROGN
*** Check the list of things which have implicit progn behavior for
*** completeness.
RETURN, RETURN-FROM
In the description of the Result argument, NIL is a form, so just say that
Result is a form.
{ Ensure that the discussion from EXIT-EXTENT is consistent with other
places (GO and THROW). }
SETF, PSETF
In the first paragraph of the description, remove the sentence
"PSETF is like SETF except when multiple argument pairs are supplied."
It adds nothing useful here.
Change the first sentence of the first paragraph of the description of PSETF
to
"PSETF is like SETF except that if more than one place-value pair is
specified then the assignments of new values to places are done in
parallel."
Currently says that new setf expansions can be defined by using DEFSETF.
Add mention of DEFINE-SETF-METHOD as well.
In the second bullet for Function Call Form places, it says
"A function call form whose first element is the name of a selector
function constructed by DEFSTRUCT."
I think the word "accessor" more appropriate than "selector".
Figure 6-39, Functions that setf can be used with -- 2, appears to be
really screwed up.
Under Any Other List, it says
"An implementation arranges that a function named (SETF reader) will
return its first argument as its only value in order to preserve the
semantics of SETF."
I don't believe the implementation has anything to do with this. A
programmer is required to write such functions correctly.
The following text, from FUNCTION-TYPE, doesn't belong here, and should be
removed.
"The consequences of setfing the SYMBOL-FUNCTION of a symbol to a symbol,
or the value returned by SYMBOL-FUNCTION on the name of a macro or a
special form are unspecified."
Also, the proposal actually says that this situation "is an error", meaning
the consequences are undefined, not unspecified.
TAGBODY
There is no discussion here of what happens if there are multiple GO tags
which are the same (EQL). I seem to remember some discussion of this
subject but haven't found any reference to it yet.
Is NIL a legal tag (see comment on GO). Description here says that tags
must be non-Nil symbols, which is wrong because it doesn't include integers,
and is inconsistent because it excludes NIL.
What does it mean to no longer be legal to GO to a tag (after the TAGBODY
form has been exited). I think this is an "undefined consequences" situation
which "might signal" a CONTROL-ERROR.
THROW
Under Conditions it says that an error of type PROGRAM-ERROR is signaled if
there is no outstanding catcher whose tag matches the throw tag. This
should be CONTROL-ERROR (see Version 18 of the Condition System).
{ Ensure that the discussion from EXIT-EXTENT is consistent with other
places (GO, RETURN, and RETURN-FROM). }
TYPE-OF
The types in Figure 6-41, Built-in-types, should instead be refered to as
Predefined types. Built-in type has a different technical meaning within
the description of the CLOS part of the language, which also uses Predefined
when discussing (essentially) these types. The types listed in this figure
correspond very closely with the Predefined Class table (Figure 2-13). I'm
going to write up an issue which will try to unify these two places.
The fifth constraint on TYPE-OF fails to mention condition types defined
with DEFINE-CONDITION. (Note that we have not specified the metaclass of
conditions).
In the notes it says:
"Implementors are encouraged to arrange for TYPE-OF to return a portable
value."
What does this mean. I believe it means that returning
si:medium-size-fixnum is legal, but that returning (integer low high), where
low and high are appropriate values for si:medium-size-fixnum, is prefered.
VALUES-LIST
Under notes it says
"(VALUES-LIST list) EQ (APPLY #'VALUES list)"
First, EQ is the wrong thing to use here. The equivelence character would
be more appropriate. But even that isn't really correct, since this ignores
the possibility that the length of the list exceeds CALL-ARGUMENTS-LIMIT but
is less than MULTIPLE-VALUES-LIMIT in the implementation the forms are being
excecuted in.
==============================================================================
Chapter 8, Glossary
1. Add an entry for "syntactic environment".