[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
r5 comments
I took a very close read through the r5 draft. Hopefully none of
these comments will be at all controversial *smile*.
-erik
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.
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.
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.
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>?
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.''
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. It should read:
``If all expressions but the last one evaluate to false values,
the value of the last expression is returned.''
or something along those lines.
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.
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))
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...''
^^^^^^^
?
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.
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. Indeed, on page 15, we have the example:
(let ((=> #f))
(cond (#t => 'ok)))
which would not be possible if => weren't allowed to be a variable.
7.3. Derived expression types -- case (page 43, right column)
------------------------------
The indentation seems to be messed up a bit here.
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 ...))))))
^^^
bug.