corrections and suggestions

[Chris Haynes <cth%iuvax.indiana.edu@CSNET-RELAY.ARPA>]

I prefer "A Report ..." or "Fourth Report ...".  In any case, remove
the bit about the ^3 not being a footnote.  No one is apt to mistake 
the title's ^3, for it is big and bold.  It is *references* to the title
in other publications where the ^3 will cause confusion, and the note
in the report won't do any good then.  

I prefer "C.T. Haynes" in the author list, and "Christopher Haynes" in the 
Background (p. 2).

In the summary, delete "and very few different ways to form expressions",
which is unnecessary and questionable.

p. 2: make those features --> make additional features
      first real programming language --> 
          first widely used programming language
      sub-dialects --> dialects
      , while many others remain to be adopted. --> .

With Kent Dybvig, I would prefer that : not be an extended
alphabetic character, but be reserved for special uses.

2.3. unspecified future uses --> possible extensions in
discussion of [ ] and { }.

3.1. may name --> names
Question: Why say "A variable that does so is said to be bound to the
location."  Is it possible to have variables that aren't bound to
locations?  If so, how?  The reader should not be kept in the dark.

Delete "Note: internale definitions not mentioned here."

3.2. #fand --> #f and

4.1 and 4.2.  The "Syntax:" and "Semantics:" paragraph flags are
nice, but are not used after "case" (p. 8).  I suggest flushing them.
Better to be consistent, and they aren't necessary for understanding.

4.2.4. Some implementations of Scheme permit a ... --> This ...

       pretty printing of (let loop ...) is messed up.

5.1. consists a sequence --> consists of a sequence

6.2. if applying a mutation procedure to one causes the other to
     change as well.
        -->
     if they have operationally equivalent values in corresponding
     positions and applying a mutation procedure to one causes the 
     other to change as well.

     For example, two pairs are equivalent if a set-car! operation on
     one changes the car field of the other.
        -->
     For example, two pairs are not equivalent if a set-car!
     operation on one does not change the car field of the other.

     Questions: is "side-effect" defined anywhere?  (A referee
     recently critisized me for not defining it.)

6.4. (in the sense of eqv?) --> (in the sense of eq?)
        [[the reader should be encouraged to think eq? on symbols]]

6.9, p. 27.  is an ordinary Scheme procedure --> is a Scheme procedure

     The classic use --> A common use

     flush "when programmers need to do something fancy,"

I don't like the last sentence of 6.9.  Opinions also differ on the
merits of SEQUENCE, but we didn't apologize for it or give SEQUENCE
less than optional status by not listing it under BEGIN as an
(optional) form.  List CALL/CC as a procedure under
CALL-WITH-CURRENT-CONTINUATION and replace the last sentence with a
statement that CALL/CC is equivalent.  Several of us feel rather
strongly about this.

6.10.1.  I also prefer CALL-WITH-*-PORT and OPEN-*-PORT.

Replace the last sentence of the WITH-*-*-FILE paragraph with
"Furthermore, when these procedures return, they close the
default port and restore the previous default.  If an escape procedure
is used to escape from the continuation of these procedures, their
behavior is implementation dependent."
[[Rational: the existing "in constrast" statement is incorrect.
Where is the contrast?  And more important, some systems will
automatically change the default port if the continuation is escaped,
but we probably don't want to even mention, let alone require, such
behavior.]]

6.10.4. Delete the LOAD rational.  The LOAD description expressly
says that expressions and definitions are read, so any uses of LOAD to
load such things as compiled files are implementation extensions anyway.

Delete the TRANSCRIPT-* Note.  We haven't provided elementary tips
to implementers anywhere else.

BIBLIOGRAPHY: add the following

Daniel P. Friedman, Christopher T. Haynes, and Eugene Kohlbecker,
Programming with continuations. {\it In Programming Transformation and
Programming Environments,\/} P. Pepper (Ed.), pages 263--274,
Springer-Verlag, 1984.


The Report reads quite well now, and has come a long way in the last
few months.  Thanks for all your efforts, Jonathan.

Chris Haynes