[r6rs-discuss] Rationale issues
andre at het.brown.edu
Tue Jun 26 09:29:14 EDT 2007
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
- (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
- (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
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.
More information about the r6rs-discuss