On Sat, Apr 16, 2011 at 10:29:25AM +0900, Alex Shinn wrote:
> The first draft of the R7RS small language standard is now
> available at:
>
> http://trac.sacrideo.us/wg/attachment/wiki/WikiStart/r7rs-draft-1.pdf
>
> This is a relatively small revision to the R5RS, adding many of
> the most frequently requested features but keeping the overall
> structure of the report the same, with a current count of 67
> pages.

First off, let me congratulate the working group with this first draft!
It's a great start of R7 and defines an elegant extension of R5RS.

I have a few comments which can hopefully be taken into account for
the next draft.

Section 2.3 (and 7.1.1):

This says vertical bars (pipe symbols) are reserved for future
extensions, which was probably copied from R5RS's wording, but it is no
longer true; see section 7.1.1.  The mention of pipes can probably be
removed from this section since 2.1 already mentions them.  The same
goes for section 7.1.1.

Section 4.2.8:

This is probably lowest priority in my comments, but it still bugged
me that the definition of quasiquote is unchanged from r5rs, which is
quite vague and allows for a lot of gratuitous diversity and
incompatibility.  See a recent discussion on Chicken-hackers:
http://lists.nongnu.org/archive/html/chicken-hackers/2010-12/msg00008.html

The main practical problem is the question of what happens when multiple
quasiquotes are nested and unquoted.  This kind of thing tends to happen
mostly in (low-level) macros and other code-generating code.

Section 4.3.2:

Why is it neccessary to define underscore as a specially-treated
wildcard?  This seems like an unneccessary feature.  I know it's an
established convention to use an underscore as "I don't care about this
variable", but people also use it in lambdas like (lambda _ 'abc) etc.
Should it be treated specially there too?

I might be missing something but AIUI when an underscore doesn't appear
in the <template> part of a <syntax rule>, the behaviour of that macro
is exactly the same whether the underscore is treated as a wildcard or
not.

Section 5.5.1:

I'm sure a lot of people will have many comments about the module
system.  For now, I'm just going to say "well done!", postpone my gut
reactions and see if the module syntax grows on me :)

Section 6.3.7:

The blob interface could be simplified by getting rid of
partial-blob and partial-blob-copy! and making blob-copy and blob-copy!'s
signatures accept optional arguments:

(blob-copy from [start] [end])
(blob-copy! from to [start] [end] [at])

"start" and "at" default to zero, "end" defaults to the length of "from".
The meaning of the arguments is the same as in the existing procedures.
This would be a more comfortable syntax IMO and it makes the API smaller.

To be more consistent with strings, "blob-copy" could also be called
"subblob".

Section 7.1:

This says case is insignificant in the BNF; but it isn't really when the
Scheme is not in case-folding mode.  Possibly only for #x and a few
others?  For example, are the <expression keyword>s case-insensitive?
If case is insignificant, why are there uppercase letters under
<hex digit>?

Section 7.1.1:

Symbols:

It's great that symbols are now quotable so that any string can be
represented as a symbol, but I have a few concerns about the way this
is implemented.

I don't like the fact that hex escapes are allowed in bare identifiers
and not allowed inside <symbol element>.

This makes the reader more complex than it has to be.  If hex escapes
were *only* allowed in pipe-delimited identifiers it's simpler; quoted
identifiers can be read using exactly the same algorithm as the one for
reading strings.  The BNF could be simplified so that
<identifier element> and <string element> map to exactly the same thing;
<quoted element> or something.  This strengthens the connection between
strings and symbols and their read/write invariance.

For bare identifiers, the syntax should be as simple as possible.
Backslashes could then be treated literally in identifiers or as an
error (or maybe leave it unspecified since different Schemes behave
rather differently here).  The main advantage of this would be that a
semicolon *always* starts a comment unless it occurs inside a quoted
symbol or string literal (or following a # reader flag, of course).

In other words:

(symbol->string 'a\b)       => "a\\b"
(string->symbol "a\\b")     => |a\\b| or a\b depending on preferred
                                default external representation
(symbol->string '|a\x42;b|) => "aBb"
(string->symbol "a\x42;b")  => aBb
(symbol->string 'a\x123;b)  => incomplete expression; wait for more input

Or in BNF:

<identifier> -> <initial> <subsequent>*
  | <vertical bar> <symbol element>* <vertical bar>
  | <peculiar identifier>

<initial> -> <letter> | <special initial>

<symbol element> -> (any character other than | or \)
  | \|
  | <quoted element>

<string> -> " <string element>* "
<string element> -> (any character other than " or \)
  | \"
  | <quoted element>

<quoted element> -> \a | \b | \t | \n | \r | \\ | <inline hex escape>

<special initial> -> (unchanged)
<letter> -> (unchanged)
<vertical bar> -> (unchanged)
<inline hex escape> -> (unchanged)

This removes <inline hex escape> from <initial>, and makes it

Actually, #"..." is even better syntax to quote identifiers since it
would remove the need to have separate <string element> and
<identifier element>s, but since most Schemes already accept pipes for
this, I'm not sure it's worth to change this.  It would make the BNF
much simpler though.

Syntactic keywords:

Finally, isn't it time to get rid of <syntactic keyword> in the BNF?
Why not let <variable> map straight to <identifier>?  Are there any
Schemes around that don't allow something like (let ((define 1)) define)?

I don't know the historical reason these are treated specially, but with
the module system they've become even more crufty.  Since it's now
possible to rename identifiers in import statements, I could create a
module in which "define" or "cond" don't mean anything special; I can
prefix/rename them to scheme:define or scheme:cond, or something
entirely different.  I could even exclude them in my import
specification altogether.

Cheers,
Peter Bex
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
							-- Donald Knuth

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