[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: r5 comments


   Date: Fri, 13 Feb 1998 13:57:47 -0500
   From: erik hilsdale <ehilsdal@cs.indiana.edu>

   I took a very close read through the r5 draft.  Hopefully none of
   these comments will be at all controversial *smile*.

Thanks for pointing these out.  Those that aren't addressed now
can be addressed later.

FYI, here is a breakdown of the version/draft of the report in
which these first appear:

 R3RS      5
 R4RS      1
 R4.95RS   5
 R4.96RS   1
 R5RS      1

   3.4 Storage model  (page 7, column 1-2)
   ------------------------------
     ``In many systems it is desirable for constants ... it is an error
     to attempt to store a new value into a location that is denoted by
     an immutable object.''

   This paragraph seems to be weaker than intended.  I read it as:

     * Some implementations flag data from literals as immutable
     * It is an error to store into an immutable object.
     * Therefore, in some implementations it is an error to store into a
       literal.

   Yet in 4.1.2 and under the descriptions of set-car! and set-cdr!, it
   is stated that it is an error to store into a literal, not merely an
   error in some implementations.

This is a long-standing problem.  I don't feel any pressing need
to do something about it now.

   3.5 Proper tail recursion (Page 7-8)
   4.3 Macros -- Pattern language (page 14)
   ------------------------------

   I'm confused as to why some parts of the text of the report use kleene
   star and plus notation, and some parts use ellipsis notation, and I
   can't see a rationale for either.  Kleene star notation seemed to be
   relegated to the formal section in r4, yet it's found its way into the
   proper tail recursion section in r5.  That would be fine, but the
   pattern language (page 14, right column) seems to be still using
   meta-ellipsis notation.  If the kleene star were to find its way into
   the non-formal part of the report (a big if), this might be one of the
   best places to use it.

Another long-standing issue, made a bit worse by the use of BNF
in the section on proper tail recursion.  At first I tried using
the ellipsis notation in that section.  It was difficult to make
it both concise and correct, mainly because of internal definitions.
The version using BNF was much simpler.

Again, I don't feel a need to fix this now.

   4.1.4 Procedures -- lambda (page 9)
   4.2.2. Binding constructs -- let let* letrec (page 11)
   4.3. Binding constructs for syntactic-keywords -- let-syntax (page 14)
   ------------------------------

   All of these contain

       ``and <body> should be a sequence of one or more expressions.''  

   This is not true, but I'm not sure you want to describe exactly what
   goes on with <body>ies in each of these sections.  

Another long-standing issue that can wait for R6RS.

   4.2.1 Conditionals -- cond (page 10, right column)
   ------------------------------

      ``Each <clause> should be of the form (<test> <expression> ...)''

   in all other explanations of syntax in section 4, any metavariable
   followed by an elipsis has a subscript (note the

      ``(<datum_1> ...)''

   in the description for case).  Should <expression> here be
   <expression_1>?

Yes.

   4.2.1 Conditionals -- cond (page 10, right column)
   ------------------------------

       ``Its value must be a procedure that accepts one argument;  this
       procedure is then called on the value of the <test> and the values
       returned by this procedure are returned by the cond expression.''

   Not that I'm wedded to the clumsy sounding ``value(s)'' wording, but
   to make this paragraph use the same terminology as the rest of the
   report it should probably be changed to:

       ``Its value must be a procedure that accepts one argument;  this
       procedure is then called on the value of the <test> and the value(s)
       returned by this procedure is(are) returned by the cond expression.''

I am not crazy about the `value(s)' wording either, but it does
get the point across.  I'll add it here as well.

   4.2.1 Conditionals -- or (page 11, left column)
   ------------------------------

       ``If all expressions evaluate to false values, the value of the
       last expression is returned.''

   This is untrue.

I don't see why.  Can you elaborate on this?

   4.2.1 Conditionals -- or (page 11, left column)
   ------------------------------

   Both here and in the description of the and syntax, we have

      ``the value of the last expression is returned.''

   This seems to imply exactly one value, rather than the value(s)
   language otherise.  If it is intended that these expressions must
   return exactly one value, then the macro for cond (in 7.3, page 43,
   left column) should be changed.  Right now, it reads:

   (define-syntax cond
     (syntax-rules (else =>)
       [...]
       ((cond (test) clause1 clause2 ...)
	(or test (cond clause1 clause2 ...)))
       [...]
       ))

   Of course, if and/or can return more than one value, this cond macro
   is fine, but then the language of the and/or expressions should be
   changed.

It's easy to change the definition of COND in 7.3, so I'll do
that.  I don't want to get into the question of how many values
OR returns.

   4.3 Macros -- let-syntax (page 14, left column)
   ------------------------------

      ``Each <keyword> is an identifier, each <transformer spec> is an
      instance of syntax-rules...''

   I'm not sure what ``an instance of'' means in this case.  In
   particular, is it meant to disallow this:

   (define-syntax sr
     (syntax-rules ()
       ((% %c0 %c ...)
	(syntax-rules () %c0 %c ...))))

   (let-syntax ((foo (sr ((% %x) (quote %x)))))
     (foo hello))

This is disallowed because macro uses are expressions, or at
least are only allowed where an expression is allowed.  The
use of `instance of' here seems clear enough to me.

   6.3. Other data types (page 25, left column)
   ------------------------------

       ``This section describes operations on Scheme's non-numeric data
       types: booleans, pairs, lists, symbols, characters, strings and
       vectors.''

   Should this be changed to read

      ``This section describes operations on some of Scheme's non-numeric...''
					     ^^^^^^^
   ?

Yes.

   6.3.2. Pairs and lists (page 26, left column, right before 
			   the description of pair?)
   ------------------------------

       ``This convention is supported so that arbitrary Scheme programs
       may be represented as lists.  That is, according to Scheme's
       grammar, every <expression> is also a <datum>''

   While the ``that is'' sentence follows from the first sentence, the
   words ``that is'' seems to imply that the second sentence is simply a
   rewording of the first sentence, which isn't true.

       every <command or definition> is also a <datum> 

   is a rewording of the first sentence.

This can wait for R6RS.

   7.1.1. Lexical Structure (page 38, right column)
   ------------------------------

       <variable> --> <any <identifier> that isn't also a
			<syntactictic keyword>>

   With the macro appendix in the body of the report, this doesn't seem
   to be true anymore.

The formal syntax is basically the syntax of the core language,
which can be overridden by macros.  I don't think this is a
particulary confusing point.

   7.3. Derived expression types -- case (page 43, right column)
   ------------------------------

   The indentation seems to be messed up a bit here.

I'll fix this.

   7.3. Derived expression types -- or (page 43, right column)
   ------------------------------

       (define-syntax or
	 (syntax-rules ()
	   [...]
	   ((or test1 test2 ...)
	    (let ((x (test1)))
	      (if x x (and test2 ...))))))
		       ^^^
I'll fix this.
                               -Richard Kelsey