[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

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

    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

  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>