[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Aaron Larson's comments
From: DECWRL::"alarson@src.honeywell.com" 4-OCT-1989 23:51:32.84
To: aitg::chapman
CC: hadden@src.honeywell.com
Subj: latest draft
I've finished reviewing sections 1 & 2 (except sections 1.1--1.3). I'm not
sure what format you want to see comments. If the following format is not
adequate, let me know and I'll resubmit them. Also, do you want comments
sent directly to you, or to cl-editorial?
My comments range from trivial to (potentially) involved. Because of
this, it would be nice to get some sort of feedback on the items that you
DON'T incorporate, that way if I don't agree, and I think the issue is
significant, I can re-comment, or raise it at the meeting. I realize that
this could be a lot of work, but I think its important.
pg 1-9, in the description of NIL. Replace "for example:" with:
Either NIL or () may be used to denote NIL. Which form to use is a
matter of style. For example:
pg 1-9 in the description of safe code:
The statement: Thus the phrase "the function F should signal an error"
... an error will be signalled. Appears wrong to me (it is consistent
with the cleanup proposals however) E.g.
(let ((safe #'(lambda (f a b) (declare (optimize (safety 3)))
(funcall f a b)))
(not-safe #'(lambda (f a b) (declare (optimize (safety 1)))
(funcall f a b))))
(declare (optimize (safety XXX)))
(funcall #'safe #'+ 1 nil)
(funcall #'not-safe #'+ 1 nil))
If the "safeness" of this program is not dependent on the value of XXX,
then I don't think we've captured the essense of "lexical property of
code" correctly in the definition of "safe code". Perhaps the statement
needs to take into account the coercion from symbol to function. If you
like, I will make a general posting about this issue.
pt 1-11, in the description of "implementations may be extended to cover
this situation", first bullet.
The phrase "at least in safe code" is redundant and should be removed.
pg 1-11 bottom:
"Every implementation is required to detect this situation in both safe
and unsafe code when the situation is detected"
The last "when the situation is detected" should be removed.
pg 1-11 last line:
"The presence of a warning will in no way alter tha value returned by
..."
Needs to be changed to read: "In the absence of condition handlers, the
presence of a warning..."
Similarly for the next paragraph.
pg 2-3, second paragraph, last sentence:
The phrase: ", but an implementation is not required to detect such
conditions" is redundant with the definition of "consequences are
undefined" and as such should be removed.
pg 2-3. The introduction is very fragmented. Needs polish. If you want,
I'll make a stab at it.
pg 2-5, figure 2-3 "condition system types"
"unbound-slot" is not in correct alphbetic sort position.
pg 2-5, in the description of NUMBER
"there are real and complex numbers" should be replaced with "Real and
complex are subtypes of number"
Either that, or the sentence and the following one should simply be
deleted.
pg 2-9, from issue character-proposal:2-1-1
"addition" should be "additional"
Also, I would put the description of standard char after the description
of base character (since it is a subtype of base char)
pg 2-10 first paragraph after enumerated list, middle of the paragraph:
"In the first implementation, the base-character is character" should
read "In the first implementation, the TYPE base-character is equivalent
to character"
pg 2-10, In description of SYMBOL
missing glossary entry for "entities" What are entities anyway?
pg 2-11, under property list:
"All indicators on a property list must be distinct from one another"
what error condition? i.e. should it read: The consequences are
unspecified if any two indicators on a property list are EQL.
also, in last (single sentence) paragraph. what does it mean
"initially"? Does this imply that all CL defined symbols must have null
plists? Or is this just a property of MAKE-SYMBOL?
pg 2-12, under simple-array & simple-bit-vector
replace the sentence "An array that is not displaced ... after creation is
a simple array" with the corresponding sentence from the cleanup issue
adjust-array-not-adjustable:implicit-copy:
1. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array.
pg 2-12, in the discussion of array and bit-vector
The types array and bit-vector are defined in terms of what they contain,
e.g. "a bit-vector is a vector composed of bits". Shouldn't this use
some words like "a bit-vector is a vector specialized to hold bits",
otherwise you could argue that if I have #(1 1 1 "foo"), and I setf the
fourth element to a 1, the array would become a bit-vector.
In the description of array, this comes up in the phrase "implementations
might provide certain specialized representations of arrays for
efficiency in the case where all the components are of the same
specialized type" I think something like "declared to be of a specified
type", or "created with a given :element-type", or some such. I don't
have good wording for this. Perhaps both could be addressed by comming
up with a definition for "specialized"
pg 2-13, under base-string
replace "most efficient string" with "most specialized string"
pg 2-13, the description of FUNCTION needs a lot of work. If you want me
to take a shot at it, let me know.
pg 2-14&15 can U use the stream types as specializers for defmethod?
The various stream-xxx types are not listed in figure 2-13. They are not
specified as being classes in the STREAM-ACCESS cleanup. Should we
entertain a cleanup to make them classes?
pg 2-16 -- 2-20 recommendation
I would drop the description of slots and accessors from the description
of the conditions. Presumably these are described someplace else in more
detail, and the redundancy is not likely to be usefull.
pg 2-20 In section "structure-object"
add "A structure-object is an instance whoose class is a subclass
of structure-class."
pg 2-21 After section "method-combination"
Add description for standard-method-combination"
pg 2-23 figure is wrong, generic-function should be a subtype of function,
and style-warning should be a subtype of warning.
pg 2-28 & 2-30, figures 2-10 & 2-12.
I would recommend alphabetizing the figures.
pg 2-30 figure 2-12 I don't have the reference that permits val-ts to
include &allow-other-keys. I coulnd't find it in CLtL, nor in the passed
cleanup issues.
pg 2-38, second par. under "modifying the structure of instances"
After "are retained", add " (i.e. they will be eql)."
pg 2-42 first par under "Introduction to slots"
"The name of a slot is a symbol...". Strike the "...". What
symbols are not syntactically valid for use as variable names?
fourth paragraph
Unless the term "visible" is defined somewhere, I would just say
"accessible", or "has :allocation :class".
General comment:
There are lots of references to "the xyx option in defclass" as being the
controlling factor for the behaviour of classes. I assume that this is
because the metaclass protocol is not going to be part of the spec.
Wouldn't it be better to just talk about the "xyz" attribute of a slot or
a class and leave it up to the reader to infer the connection (or just
say it once in the description of defclass)?
pg 2-44 third Par from bottom starts "A consequence of the type rule is
that"
The sentence starting "Because the result of..." is attempting to
partially define an undefined situation. It should just read: "The
results of attempting to store in a slot a value that does not satisfy
the type constraint for the slot is undefined."
General comment:
The rest of this chapter (from pg 46 to 55) appears to be quite
disorganized. If this material is covered some place else in the
standard, then I would recommend that these sections simply be
eliminated. If this material is not covered someplace else, then lots
more work is going to be necessary to make it hang together.
pg 2-46 section titled "initialization arguments"
This section is real weak (e.g. the m-n relation between initargs and
slots is not discussed at all). I would recommend either beefing this
section up, or just punting and letting a later section define it better.
pg 2-48, second par.
Need to say that :default-initarg forms are evaluated at the time of
make-instance, and hence potentially more than once (i.e. as many as once
for every object).
pg 2-51, section "definitions of make-instance and initialize instance"
example at bottom of page.
What is the function default-initargs supposed to do? I would delete
this whole section.
pg 2-53 section "customizing the change of class of an instance"
The whole paragraph appears to me to be superfluous.
similarly for section "customizing reinitialization" on pg 2-54.
% ==== Internet headers and postmarks (see DECWRL::"GATEWAY.DOC")
% Received: by decwrl.dec.com; id AA02055; Wed, 4 Oct 89 20:51:31 -0700
% Return-Path: <alarson@src.honeywell.com>
% Received: from pavo.src.honeywell.com by src.honeywell.com (4.0/smail2.6.3/SRCv0.25);
% Wed, 4 Oct 89 22:51:23 CDT id AA16041 for chapman@aitg.enet.dec.com at aitg.enet.dec.com
% Posted-Date: Wed, 4 Oct 89 22:51:19 CDT
% Received: by pavo.src.honeywell.com (4.0/SMI-3.2)
% id AA11298; Wed, 4 Oct 89 22:51:19 CDT
% Date: Wed, 4 Oct 89 22:51:19 CDT
% Message-Id: <8910050351.AA11298@pavo.src.honeywell.com>
% In-Reply-To: 19-Sep-1989 1711's message of Tue, 19 Sep 89 17:52:31 -0700 <8909200052.AA00362@decwrl.dec.com>