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

[Scheme-reports] Draft 3 Comments: Chapter 4

Hi,

I haven't found anything to complain about in chapter 3, so here are my 
comments on the fourth chapter:

It is sad to see that much of this section has been essentially copied 
unchanged from R5RS; many things here were fixed, clarified or simply 
more nicely edited in the R6 report. Here are some examples:

* The descriptions show a general lack of awareness wrt multiple
   values in many places. There are several instances of "value(s)",
   "result(s)" and "is(are)" kludges that feel like afterthoughts, and
   many phrases that assume a single value (e.g., in the description
   of "and" - "the value of the last expression is returned"). R6RS
   handles this nicely by uniformly using the plural "values" /
   "results",which logically includes the single value case.

* The R5RS-inherited descriptions are not very consistent regarding
   the description of syntax elements. While it is clear that, e.g.,
   <expression> should be an expression, this is not so clear in other
   cases, such as <test>; at some places, R5RS (and thus R7RS) says
   that <test> must be an expression ("if"), at some places it is
   omitted and must be inferred from the semantics ("and" / "or").
   I like R6RS better here, which consistently points such things
   out. (The R6RS description of "and" has "Syntax: <test> must be
   an expression.")

These are only two points that I specifically noticed, but there are 
probably other ways in which the R6RS descriptions are better. Don't let 
this work be wasted! I recommend you to look at R6RS thoroughly here and 
and evaluate what can be incorporated into the draft.

(As an aside, the editorial work done for R6RS should serve as an 
inspiration in general. For instance, I really really like the excellent 
"Overview of Scheme" chapter in that report; it would be awesome if that 
would be integrated.)

With all that said, here are some more concrete remarks about the newly 
written sections:

4.2.1. Conditionals
===================

I was a bit suprised to see that the results of "when" and "unless" are 
left completely unspecified. The obvious thing to specify would be that 
they return the last expression in the body if evaluated, wouldn't it? 
That is also how R6RS defines it. A proposal with wording from that report:

"(when <test> <expression1> <expression2> ...)

Syntax: <test> must be an expression.

Semantics: The <test> expression is evaluated. If <test> evaluates to a 
true value, the remaining expressions are evaluated in order, and the 
results of the last expression are returned as the result of the entire 
when expression. Otherwise, the result of the when expression is 
unspecified."

"unless" could be described in a similar fashion.

4.2.2. Binding constructs
=========================

letrec*
-------
It seems as if the description of letrec* is essentially copied from 
letrec and only slightly modified, which feels kind of odd and 
"mechanical". I would have expected something along the lines of the 
description of let* - "like letrec, but ...". Just a feeling, though.

4.2.3. Sequencing
=================

begin
-----
The description of "begin" speaks of "forms" (e.g. "It must appear as a 
form in a <body> [...]"). While this is common Lisp terminology, it is 
never defined or otherwise used in the report. Possible solutions to 
this problem could be to use of a clearer term such as "syntax form" 
instead or, even better, to introduce such terminology in the "Overview 
of Scheme" chapter (as R6RS does; see section 1.5 "Forms" there).

It would also be nice to point out that "begin" is also used as the body 
of a module form, with a reference to the relevant section (5.5).

4.2.6 Dynamic Bindings
======================

parameterize
------------
I see two problems with the description of "parameterize". The first is 
that it uses "form" the same way as noted above. ("The parameterize form 
is used [...]") The second is that it is, in general, quite confusing as 
the notion of "parameter objects" has not been introduced in previous 
sections, yet is used here without explanation. Only the last sentence 
gives a hint as to where to look what parameter objects are in the first 
place. I think that needs some reorganization. At the very least, the 
first sentence should already include the relevant reference:

"The value of each <param> expression must be a parameter object (see 
make-parameter in section 6.4). [...]"

(By the way: "param" and "value" are incorrectly formatted and are 
missing square brackets.)

guard
-----
I guess that the sentence "The final expression in a cond clause is in a 
tail context if the guard expression itself is" was copied from the R6RS 
description. It is inconsistent with the rest of the report, though; 
instead, the sentence should be removed and "guard" added to the list of 
tail context forms in section 1.3.5 (where it isn't listed currently).

quasiquote
----------
In the sentence "The external syntax generated by write for two-element 
lists whose car is one of these symbols may vary between 
implementations", I think "car" should be monospace.

case-lambda
-----------
Maybe the example can be modified to include a case which calls another 
case of the same procedure? This would illustrate the common use of 
reducing different cases to a base case, while still being able to 
completely special-case in particular situations.

4.2.10 Reader labels
====================

Placing this section next to the derived expression types seems kind of 
odd. Reader labels cannot be derived from simple expressions. In fact, 
it is hard to argue that they are expressions at all; they are just a 
way of expressing possibly cyclic structures.

Also, the name "reader labels" is problematic because the report doesn't 
have the notion of a "reader", only of "the read procedure" (see my 
comments regarding chapter 2). "Read labels" would be a better fit.

4.3.3 Signalling errors in macros
=================================

syntax-error
------------
A reference to "error" (section 6.5) is missing.



I know, that was quite a lot of criticism... please don't take this as 
offense! You have a very difficult job to do and do it great, and I 
admire you all for doing so. I hope I am able to help this way. :)

Regards,
Denis

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports