[Scheme-reports] Draft 3 Comments: Chapter 4

[Scheme-reports] Draft 3 Comments: Chapter 4 Denis Washington 27 Jul 2011 12:34 UTC
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@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports