[Scheme-reports] Issues from read-through

[Chris Hanson <cph@x>]

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.

I apologize in advance if some of these were discussed on the record
and I'm re-hashing old issues.  I haven't read the discussion archive
so I'm ignorant of the history.

I'm pretty sure this isn't the current draft, but it's the one I have
a printed copy of, and I'm on vacation without a printer.

Draft March 18 2013

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".

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.

Section 2.3, paragraph 1:

        Note that a sequence of two or more periods is an identifier.

    Is |.| an identifier?  Maybe clarify here.

Section 2.4, paragraph 1:

        It is an error if <n> is not a sequence of digits.

    Should be "non-empty sequence".

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.

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.

Section 3.2, paragraph 1:

    Should error? and/or promise? be added to this list?

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.

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.

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.

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.

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.

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.

Section 6.9:

    Why bytevector-u8-ref and bytevector-u8-set! rather than just
    bytevector-ref and bytevector-set!

Section 6.10:

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

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