• Home
• All tickets
• All wiki pages

Source for wiki PlebisciteObjections version 6

author

cowan

comment

ipnr

173.13.139.236

name

PlebisciteObjections

readonly

0

text

'''Work in progress, please ignore for now'''


* 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.
 * Perhaps that is because they are pure R6RS.  We can't do it all.
* 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 by always wrapping it 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.
 * Scheme would probably be better off not treating strings as sequences of characters, but rather treating characters as a special case of strings.  Unfortunately, that's too far away from the IEEE model.
* 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-13 01:00:04

version

6