[r6rs-discuss] Rationale issues

From: AndrevanTonder <andre>
Date: Tue, 26 Jun 2007 09:29:14 -0400 (EDT)

A few comments on the rationale:

  - (6.3) Local modules:

    The document states "it is debatable whether top-level library is (or
    should be) the same construct as local module". However, I disagree
    that the draft has left this open for debate. The decision that
    library names are not identifiers has in effect closed the debate,
    preventing local modules from being libraries. This decision should
    probably be acknowledged or changed.

  - (6.7) "Using compound compound names ...", is perhaps more true
    than the editors intended. Also, a spell check of the rest of the
    document might be useful ;-)

  - (6.7) "Versioning, in particular, is natural in list form, but awkward
    in encoded form." - This is the only rationale mentioned in favour of
    compound names. However, it is clear what versioning as lists has
    nothing to do with library names as lists, and should be removed from
    this section. So effectively there is no rationale for list
    library names left.

  - (6.8) "Versioning", does not rebut the arguments against source-level
    versioning stated recently in this list. No one has argued for the
    absence of versioning information, when needed, at a different level
    outside the purview of r6rs. The stated "experience ... consistently
    indicates" assumes ignorance of the fact that the problem has largely been
    solved in great detail and generality by widely used third-party
    versioning systems.

  - (6.9) If it is not clear that prior experience applies, it may be
    better not to mention it.

  - (9.9.1) Since r6rs libraries would in principle allow ... and _
    to be usefully employed both as literals and special pattern matching
    directives in the same macro, some justification for continuing
    to disallow these identifiers as literals (if kept) may
    be useful.

  - (15.1) "Therefore, the parent clause only accepts other
    record types defined using the syntactic layer." - I do not think
    the argument given implies the necessity of the "therefore", since
    an implementation can determine for itself whether the parent
    has been defined via the syntactic layer and optimize or not based
    on that determination. More seriously, I think
    this restriction impedes modularity - changing
    a definition from syntactic to procedural in some library
    may break dependent libraries even if no properties of the
    record type (other than the mode of definition) has been changed.
    In fact, the mode of definition becomes an extra property of the
    data type, so the "syntactic layer" is not really a "layer" but
    introduces new things.

  - Chapter 22 (Enumerations):

    "Different Scheme implementations have taken different approaches to this
    problem in the past, which suggests that a default policy
    does not merely encode what any sensible programmer would do anyway."

    Should the "does not" be there? Also, some comments on this list
    has led me to believe that different implementations are likely to take
    different approaches also in future, but I guess that is a discussion
    that has already been had.

  - Chapter 23 (Composite library):

    "The (rnrs (6)) library exports all bindings for expand as well as run so
     that it is convenient for writing syntax-case macros as well as run-time
     code."

    It is not necessary for the stated convenience to
    include useless exports of SYNTAX-RULES, etc. for RUN and useless
    exports of DEFINE-SYNTAX, LET-SYNTAX, etc. for expand. If these are
    kept, some rationale for it may be helpful.

Andre
Received on Tue Jun 26 2007 - 09:29:14 UTC