Chris Hanson scripsit:

> Here are a bunch of issues I identified, some editorial and some
> substantive, while I read the draft report.  Please take care of the
> editorial issues; it's probably too late to do anything for the other
> issues, but I've included them for the record.

These are solely my responses.

> Section 1.3.3, paragraph 2:
>
>         ...; for example, <expression> stands for any string of
>         characters which is a syntactically valid expression.
>
>     Change "which" to "that".

This is a grammatical superstition rather than a rule.  See
<http://stancarey.wordpress.com/2011/10/18/that-which-is-restrictive/>
for details.

> Section 2.1, paragraph 3:
>
>         Note that || is a valid identifier that is different from any
>         other identifier.
>
>     A tautology; ANY identifier is different from ANY OTHER
>     identifier.  Either drop this sentence or change wording to have
>     some meaning.

Of course you are correct; this sentence was meant to be helpful rather
than defining (the actual definitions are in section 7.1).

> Section 2.3, paragraph 1:
>
>         Note that a sequence of two or more periods is an identifier.
>
>     Is |.| an identifier?  Maybe clarify here.

Same answer.  Just trying to show that while . is not an identifier,
.. and ... and .... etc. are identifiers.  And yes, |.| is an identifier.

> Section 2.4, paragraph 1:
>
>         It is an error if <n> is not a sequence of digits.
>
>     Should be "non-empty sequence".

Picky, picky, picky.  The formal syntax controls.

> Section 3.1, paragraph 2:
>
>         The most fundamental of the variable binding constructs is the
>         lambda expression, because all other variable binding
>         constructs can be explained in terms of lambda expressions.
>
>     Except top-level bindings.

I believe this is worth fixing and will add it to the errata.

> Section 3.1, paragraph 3:
>
>         If there is no binding of the identifier whose region contains
>         the use, then the use refers to the binding for the variable
>         in the global environment.
>
>     Here, and in many other places, the word "global" is inaccurate
>     and misleading.  There is no global environment in Scheme as
>     described in this report; only top-level environments, one per
>     program or library.

There is also the interaction environment, which controls what happens at the
REPL.  "Global" is a synonym for "outermost in the current context",
though we probably should have said so.

> Section 3.2, paragraph 1:
>
>     Should error? and/or promise? be added to this list?

No, they are not guaranteed disjoint.

> Section 4.1.4, bullet item 2:
>
>         <variable> The procedure takes any number of arguments; when
>         the procedure is called, the sequence of actual arguments is
>         converted into a newly-allocated list, and the list is stored
>         in a fresh location that is bound to <variable>.
>
>     It would be nice if it were an error to modify this list.  That
>     would give implementations some useful flexibility.

It would indeed be nice; alas, it is not Scheme.  IMHO there should have
been privileged accessors to an opaque rest-argument-object rather than
having Scheme-the-language tied to the standard Scheme data structures,
but it's too late now.

> Section 4.3.2, paragraph 3:
>
>     I wish we had never allowed vector patterns and templates.  That's
>     just a bad idea, adding additional ways to write things that
>     provides no real expressive power.

From what I understand, these are necessary in order to allow
quasiquotation of vectors to be implemented using syntax-rules.  I myself
don't understand how the quasiquote macro works, so I can't affirm this.

> Section 5.2, paragraph 1:
>
>     What if a library exports the name "import"?  Or "define-library"?
>     At a minimum, there should be some text regarding this case.  One
>     obvious solution is to ban their use as identifiers.  Another,
>     which I prefer, is to change the "empty" initial environment to
>     contain only the standard bindings for those identifiers.

I can only respond vaguely by saying that import and define-library are
not really bound to anything: they are recognized verbatim, as the names
of library declarations are.  In a sense they are outside the Scheme
scheme of things.

> Section 5.6.1, last paragraph:
>
>         Regardless of the number of times that a library is loaded,
>         each program or library that imports bindings from a library
>         must do so from a single loading of that library, regardless
>         of the number of import declarations in which it appears.
>
>     This avoids saying what happens if two distict programs or
>     libraries import from the same library.  Since a library can have
>     top-level side effects, this must be specified.  Alternatively,
>     the report could forbid top-level side effects, but this gets
>     complicated pretty quickly and would be hard to prove in a
>     compiler.

This is the same freedom that R6RS allows.  I think it's probably
a mistake (libraries should be loaded once and only once per program
execution), but we didn't want to be semantically incompatible with R6RS
in this respect.

> Section 6.6, paragraph 5:
>
>         Case is significant in #\<character>, and in #\<character
>         name>, but not in #\x<hex scalar value>.
>
>     It seems to me that #\<character name> should be case insensitive
>     and limited to ASCII.  In addition, it would be desirable if the
>     character names were the Unicode names, replacing spaces with
>     hyphens (or underscores), with the addition of the historical
>     character names where those differ.

We voted on the Unicode names as well as the W3C entity names as
non-normative sources, and decided not to say anything.  Some of the
Unicode names, however, are awfully long: consider LATIN SMALL LETTER N
WITH LONG RIGHT LEG, or ARABIC SYMBOL THREE DOTS POINTING DOWNWARDS ABOVE.
Making them case-sensitive allows TeX-style and W3C-style contrasts like
#\Iota (capital iota) vs. #\iota (small iota).  I agree that ASCII-only
might have been a sensible restriction.

> Section 6.7:
>
>     This would have been a good opportunity to provide for immutable
>     strings, and push the mutability procedures into an optional
>     library.  The mutable-string design, which is my fault given that
>     I defined the string operations in RRRS, is in hindsight a real
>     mistake.  There's no good reason for strings to be mutable, and
>     requiring them to be precludes many useful implementations, e.g.
>     a simple UTF-8 encoded bytevector.

A boxed bytevector is usable, however, though expensive in terms of time
and space.  Mutable strings were the thing I most wanted to get rid of,
but my sense of the WG was that removing string mutability, which is
required by IEEE, was too big a change.

> Section 6.9:
>
>     Why bytevector-u8-ref and bytevector-u8-set! rather than just
>     bytevector-ref and bytevector-set!

In the large language there will be bytevector-u16-ref and many others.
Bytevectors in the large language are a sort of hybrid between
simple blobs and u8vectors.  There seemed little point in providing
bytevector-ref in the small language and a synonymous bytevector-u8-ref
in the large language.

> Section 6.10:
>
>     Given that there are operations for all sequence types except
>     bytevector, why was the latter excluded?

Same answer: it is more of a blob type than a sequence type.
The large language will allow treating it as many different sequence
types, which would have been overkill for the small language.  See
<http://trac.sacrideo.us/wg/wiki/NumericVectorsCowan> for a detailed
proposal.

--
Do what you will,                       John Cowan
   this Life's a Fiction                cowan@ccil.org
And is made up of                       http://www.ccil.org/~cowan
   Contradiction.  --William Blake

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