• Home
• All tickets
• All wiki pages

Source for wiki PlebisciteObjections version 2

author

cowan

comment

ipnr

173.13.139.236

name

PlebisciteObjections

readonly

0

text

I (John Cowan) have extracted the following formal and informal objections to draft 9 of R7RS-small from votes cast in the R7RS-small plebiscite.  I have in some cases provided suggested resolutions for the WG as well.

* The draft semantics of `eq?` and `eqv?` as applied to procedures should return to the IEEE/R5RS rules.
 * WG1 has already unanimously agreed with this.
* The draft is gratuitously incompatible with R6RS.
 * R6RS in turn was incompatible with existing practice as expressed in SRFIs and implementations.  Many of the incompatibilities in the draft were meant to be compatible with this existing practice.
* The proposed module system is pointlessly inflexible.
 * The only way to extend the module system in R6RS is through the use of syntax-case macros, which were considered to be too complex and controversial for R7RS-small.
* The proposed module system requires additional boilerplate past the requirements of R6RS and implementation-specific module systems.
 * Only a little.  You can convert an R6RS module into the draft's module language by changing `library` to `define-library` and wrapping everything except the `import` and `export` declarations into a `begin` library declaration.  (Of course, this assumes that the implementation provides both R6RS and R7RS modules for import.)
* The semantics of the top level are unspecified in the draft.
 * They are not entirely specified, it's true.  But there is no reason for something to be either 100% specified or 0% specified.  A standard is a contract between user and implementer, and it may quite legitimately partly constrain the implementer or user while still providing some freedom of action.
* The draft avoids making hard decisions, making it a mere description of the current state of Scheme.
 * A standard is inherently a compromise.  A rigid "my way or the highway" standard, especially a complex one, means that only a few implementers will be able to provide it, thus limiting the scope of user choices.
* Many decisions were based on a tacit requirement to ignore R6RS.
* The draft is a step backwards (or at any rate fails to be a step forwards) from R6RS.
 * The R7RS-small language is not meant to replace R6RS.  Rather, it is meant to replace R5RS and at the same time provide a sound basis for the R7RS-large language, which is meant to replace R6RS.
* The draft fails to stay true to the history and spirit of Scheme.
 * A matter of opinion.
* The draft's failure to treat compatibility with R6RS as important is a move away from unity.
* For aficionados of Scheme's crystalline beauty, the draft has little to offer beyond R5RS.
* It's a matter of opinion whether Scheme's procedure librar (which is greatly extended) is a matter of diamond-like beauty in ''any'' version of the Scheme standard.  It is for the most part ad hoc and historical.
* The draft has little to offer the working programmer over R6RS.
* The draft fails to provide library versioning, a pedagogically important topic.
 * The WG's view is that the R6RS library versioning system was insufficiently tested against implementations when it was proposed, and hasn't received much attention since.
* The draft excludes assertions.
 * True.
* Programs that depend on full Unicode support are not portable to all R7RS implementations.
 * True.  However, many programs in the domain of the small language do not require extensive character support, and Unicode support is emphatically not free.
* The syntaxes `include` and `include-ci`, and the `load` procedure, don't belong in Scheme.
 * The `load` procedure has been around
* The draft does not provide the important higher-order procedures in the R6RS `(rnrs lists)` library.
* The draft does not require the Scheme language to be safely implemented in conforming implementations.
 * Not mandating safety allows implementations to trade off safety for performance for the sake of users and programs who need that performance.  This can be done either by a safety setting in a single implementation or by allowing pervasively unsafe, yet conformant, implementations to be created.
* The draft defines a less expressive language than the R6RS base language.
* The "stack-winding dance" of `guard` clauses is not dealt with in a satisfactory way.
* Mutable strings are still present in the draft despite their undesirability.
* The draft insists that certain procedures return a single unspecified value rather than an unspecified number of unspecified values.
 * That provision makes it possible to invoke an unknown procedure safely without needing to wrap it in `call-with-values` or an equivalent.
* Adding Unicode support is too large a change from R5RS.
 * It is still possible for a Scheme to provide ASCII-only support; the only constraint is that it must be done in a way that extends smoothly to the rest of the Unicode repertoire.
* Exceptions integrate badly with the rest of the language.
* The syntaxes `#true` and `#false` are totally gratuitous.
 * They add a little extra readability, but are optional.  Early versions of the Scheme standard provided them in the forms `#!true` and `#!false`.
* The lexical syntax `#| ... |#` is unsightly.
 * A matter of taste.  Many Schemes provide it already, including R6RS.
* The lexical syntax `#!(no-)fold-case` is a bit ugly.
 * It is R6RS-compatible and fairly clear.  The alternatives `#cs` (case sensitive) and `#ci` are less widely standardized and less intuitively clear.
* The `read-line` procedure can cause a denial of service because it does not provide for a limit on the amount of input read.
 * True.  However, `read` has the same problem.  It's easy for an implementation that worries about this sort of thing to provide an optional second argument setting a limit.
* The syntax of `define-record-type` is unscalable and not open to extension.
 * True.  However, it is extremely widely implemented, more so than any other non-R5RS syntax or procedure.  WG members who voted for it emphasized the importance of compatibility.
* The systematic use of parameters would be better than proliferating separate procedures, specifically in the `write`, `write-simple`, and `write-shared` procedures and the `include` and `include-ci` syntaxes.
 * Au contraire.  If that were done, the only safe way to call `write` would be wrapped in a `parameterize` form, which is longer and less clear.  Syntax forms are not affected by the state of (run-time) parameter objects.
* The `error` procedure is gratuitously different from the R6RS version.
 * Which in turn was gratuitously different from SRFI 23.
* The `include`, `include-ci`, and `include-library-declarations` syntaxes are ugly and unnecessary consequences of the artificial limitations on modules.
* The `cond-expand` syntax does not scale well, and we have done little to fix the issues that make it un-useful.
* The lack of a fully-featured macro system requires the use of sub-par constructs.
 * There are too many fully-featured macro systems around, and WG1 believed that none of them were appropriate for the small language, bringing in as they do considerations of phasing.  There is no reason why the large language cannot provide more than one.
* The draft's version of Scheme has no conception of user extensibility in the library system or conditional expansion.
 * The module system is the largest mandatory extension to R5RS.  Keeping it simple and static rather than allowing greater generality seemed to the WG to be the appropriate tradeoff between flexibility and ease of use and implementation.  Not everything in Scheme is designed for maximal flexibility.
* The draft follows the style and wording of R5RS rather than the better, more precise, and clearer R6RS language.
 * A matter of opinion.  John Cowan personally does not believe that changing every occurrence of "number" to "number object" actually helped either precision or clarity.
* The draft should reflect the intersection of high-quality industrial-strength implementations, not the intersection of every toy Scheme ever written.
 * Which implementations are those?  Schemers disagree.
* The `call/cc` abstraction is intractable and not useful and should have been excluded.
 * The WG did not believe that the very high bar for removing an IEEE Scheme feature was met.
* The draft was forbidden by its charter to remove restrictions that make additional features seem necessary.
 * If the restrictions in question were hard-coded into R5RS, and removing them would break backward compatibility, then yes.  Restrictions that could be removed without breaking backward compatibility could be and sometimes were removed; for example, the restriction that `load` loads into the interaction environment only.
* The large language should have been developed before the small language.
 * This objection is untimely.  In addition, developing a large language and then subsetting it would have a higher overall risk of failure; if the large language was never completed, the small language would not exist.
* The text-handling routines are redundant or inelegant in a Unicode world, but could not be removed or fundamentally altered due to charter restrictions.
* The interaction between exceptions, `dynamic-wind`, and continuations is missing something orthogonal.
 * This objection is too vague to meet head-on.
* Parameters don't belong in the base language.
 * They can be provided portably on top of `dynamic-wind` provided the implementation does not provide native threads.  In the presence of threads, however, such a portable implementation will produce unintuitive results.
* The draft made many matters settled by R6RS undefined again.
 * Since R6RS support never became pervasive, these matters were in practice not defined in a way that Schemers could rely on, unless they used only R6RS-compatible implementations.
* The order of arguments in the draft's `bytevector-copy` is fundamentally incompatible with R6RS in an undetectable way, though it is R6RS that is wrong here.
 * True and unfortunate, but the draft's approach is consistent with the rest of Scheme.
* The draft should have included delimited continuation support.
 * The large language will provide it.
* The draft does not provide procedures that operate on mixed types of sequences (e.g. a map function that accepts a list and a vector and applies a two-argument function element-wise on them).
 * True.  Unfortunately, no one proposed them during the working life of WG1.
* The draft is too conservative in its changes to R5RS.
 * That was a charter requirement.

time

2013-05-11 10:32:34

version

2