• Home
• All tickets
• All wiki pages

Source for wiki SixRejection version 1

author

cowan

comment

ipnr

66.108.19.185

name

SixRejection

readonly

0

text

These are condensed and anonymized [http://www.r6rs.org/ratification/results.html#X67 reasons given by the people who voted against R6RS], with comments underneath them that shows how R7RS meets (or fails to meet) the objection.  '''This document is still being edited.'''  All errors are Cowan's responsibility.

 * Interoperability should not be achieved by demanding that one size fits all.  Requiring all of the many features of R6RS limits the capacity of the implementors to work in small, specialized fields.  Embedded devices immediately come to mind, but other things also come to mind, such as applications that may not desire unicode, libraries, or other pieces.  R6RS removes the aspects of elegant simplicity and limited scope that make Scheme such a great language for teaching. Right now, Scheme is easy to learn, because the core concepts are simple, and they extend outward in reasonable, predictable ways.

  ** R6RS is about 340% the size of R5RS.  By contrast, R7RS-small is about 50% larger than R5RS, but only the base library is required, and that is actually smaller than R5RS.

 * The change to case-sensitivity flies in the face of Scheme tradition, for little to no benefit.  Existing programs that assumed case-insensitivity will have to be massively overhauled.

  ** R7RS permits case-insensitive code files to be included in modules without making any changes to the files themselves.

 * R6RS has simply suffered considerable feature creep and is vastly overspecified and overcomplex. In a word, it is too ambitious (or presumptuous, depending on your point of view). It will make Scheme too much complicated for a gain not worth it.  We should focus on defining vital SRFIs, and that we all agree on portable extensions of Scheme, to implement, say, TCP/IP, non blocking IOs or bindings to a graphical library.

  ** R7RS-large is expected to consist of a series of optional packages, some of which will be closely aligned with existing SRFIs.

 * It is not clear what problem implicit mantissa widths solve, and they are ill-defined.  Explicit mantissa widths are "additional features", the need for which should be eliminated by removing restrictions against non-decimal floating-point values.

  ** Neither implicit nor explicit mantissa widths are provided in R7RS.

 * There is no need to embed library versions in import specifications. Matching library versions should be solved outside of the language.  Everything done with versions in the current draft could be added in a backwards compatible manner in future drafts.  Also, the version reference syntax is very complex and rather ugly.

  ** Version numbers are not a feature of R7RS libraries.

 * Implementations should be allowed to support characters beyond Unicode.

  ** R7RS permits this.  

 * File-options, buffer-mode,etc., are provided as syntax rather than procedures.

  ** The R6RS I/O system

 * Identifier syntax is purely syntactic sugar that complicate the semantics of the language.  Identifiers may no longer be simple variable references, making code potentially more difficult to read.  This breaks R5RS compatibility by eliminating a specific invariant on which R5RS programs and macros can rely, namely that a reference to an identifier has no side effects.  It weakens every macro in the entire language by removing knowledge about the language the macros are expanding.  Code-walking macros become more difficult to write.

  ** R7RS-small does not provide identifier syntax.  At present, R7RS-large does not provide it either, but that may change.

 * The `syntax-case` macro system is an unfortunate choice.  Both syntactic closures and explicit renaming macros are older, and are simpler and more in the spirit of Scheme.

   ** R7RS-small provides only `syntax-rules`.  R7RS-large currently provides for explicit renaming, but this may change.

 * The R6RS treatment of `_` and `...` patterns.  It's unfortunate that R5RS macros can't match `...` as a literal in templates, but with the same restriction on `_` many existing macros will break, and moreover they have no easy workaround, requiring otherwise simple pattern matching macros to be rewritten in much longer and more convoluted low-level code.

  ** R7RS-small adopts these conventions of R5RS, but also adopts SRFI 46.

 * Unicode.  Scheme has been around for a long time, and has seen many encodings come and go - there's no reason to bind it to a single encoding forever.

  ** R7RS does not require the whole Unicode repertoire to be supported, but does things the Unicode way.

 * The normalization procedures handle normalization at the wrong level.  It's inherently an encoding issue, and is best treated as such.  Providing this functionality at the string level forbids the implementation strategy of keeping all strings in the same normalization form - a very appealing strategy on many levels.

  ** R7RS-small provides only normalized comparison procedures rather than normalization procedures.

 * O(1) string access suggests that all Schemes should use UCS-4 character vectors for their string representation, discouraging the use of alternate representations such as UTF-8 and ropes or trees.

  ** R7RS does not prescribe O(1) access time.

 * Character-level case mappings encourage programmers to write broken algorithms.

  ** Unfortunately, they are an IEEE Scheme feature and can't easily be removed.

 * The I/O system was totally rewritten for no reason, and all aspects of it are controlled with gratuitous syntactic forms - second class forms which discourage high-level procedures.

  ** R7RS-small provides only R5RS I/O plus a close parallel of it for byte I/O.  R7RS-large will have a more complex I/O package, but its content is not yet defined.

 * There's simply no reason for enumerations, since Scheme has traditionally used symbols for the same purpose.  It is an example of premature generalization and piling feature upon feature.

  ** They are not in R7RS-small; the R7RS-large situation is still open.

 * Exceptions.  The exception system is far too large and over-specified. Implementations should be free to experiment with extensions in these areas.  The division into simple and compound conditions, along with the infrastructure required to manipulate these, is overly complex and may be awkward to use in practice.

  ** R7RS-small provides the R6RS ''exception'' system, but not the ''condition'' system; a condition can be any Scheme object.

 * The constructor-related parts of the syntactic record layer and of the procedural layer are bewilderingly complex.  The custom constructor design is a good example of premature generalization and piling feature upon feature, and their current API adversely affects other aspects of the design, such as modularity.

  ** R7RS-small provides only a SRFI-9-compatible syntactic record layer.  R7RS-large will probably provide SRFI 99 records or something very like them.

 * There is no way of importing `set!` for a single level.  The composite library should not export define-syntax and let[rec]-syntax for level 1, or syntax-rules for level 0.  In the context of the (rnrs) import, there is nothing one can do with these bindings at those levels.

  ** R7RS-small does not provide phasing, as its only macro system is `syntax-rules`.  The question is still open for R7RS-large.

 * R6RS links library instantiation and visitation not to import clauses, but instead to the presence of identifier references in the client, and provides no guarantee of instantiation otherwise.

 * The description of the mark-antimark for the `syntax-case` algorithm significantly lengthens and increases the complexity of this chapter.

  ** R7RS-small does not provide `syntax-case`.  R7RS-large macro systems are still open.

 * The standard library report gratuitously eschews important and widely-used existing SRFIs (such as the SRFI-1 list library, and SRFI-69 hash tables) in favor of its equivalent incompatible functionality.

  ** R7RS-small has changed R5RS in small ways for SRFI-1 compatibility.   SRFI-1 is currently planned to be incorporated into R7RS-large.  R7RS-large will provide hash tables, but the exact form is still open.

 * Why should features such as, say, byte vectors, enumerations and hash tables should even be included in the RnRS reports in the first place?  The SRFI process has proven itself and works better than the committee process being voted on here.

 * There is nothing to indicate that the editors ever considered the inclusion of multidimensional arrays, even though they are the subject of SRFI-25, SRFI-47, SRFI-58, and SRFI-63, and portably supported by SLIB.

 * The R6RS library mechanism fails to be modular; users must know and exclude from modules any exported redefinitions, whether or not they use those identifiers!

 * Requiring the full numeric tower works against using Scheme in smaller environments such as embedded systems.

 * Procedures such as `div0-and-mod0`, `exact-integer-sqrt` simply do not belong in a base language.  In fact a lot of the numerical procedures belong in a library.

 * It is perfectly meaningful to say that if a specific library is implemented, it must meet the entire spec. but ''all'' libraries must be optional in a base language and a base language implemener ''does not'' have to provide all libraries.

 * R6RS is not good enough for commericial usage since it lacks a FFI to interface it with libraries implented in C/C++, and it specifies too much for an experimental language.  Neither fish nor fowl.

 * R6RS should be *smaller* than R5RS, where some of the required features get moved to optional.

 * R6RS has the goal of making Scheme be like C or Perl: a workable programming language like other programming languages.  This seems reasonable on its face, but Scheme has survived for a long time by not being a programming language like others, but rather by being an oddball: minimally specified, usable for real-world programming only by using numerous implementation-specific features, but ideal for teaching and research.

 * It is not clear that R6RS even specifies the right things to make Scheme industrial strength.

* Each new large feature (enums, records, conditions, identifier macros, Unicode) are each individually motivated, but all together we end up with a very large ball of mud.  The size of this ball directly impairs one of Scheme's important features from an industrial perspective: its role as a small language suitable for automatic program transformation and other PLT sorts of techniques.

 * R6RS does not provide homogeneous numeric vectors.  The suggestion is made in the rationale that bytevectors plus sealed and opaque types can lead to efficient implementations of them.  This assumes the existence of a "suitably smart compiler".

 * R6RS I/O is lacking support for PGM/PPM files, open TCP sockets, and other features.

 * R6RS does not provide unsafe arithmetic or list operations.

 * The fact that bytevectors are, by their nature, type aliasing nightmares is too lightly ignored in the draft.  Making these the basic implementation strategy of homogenous vectors makes it harder for Scheme systems that compile to C for portability to implement homogeneous vectors efficiently, due to the C aliasing rules.  IEEE-754 does ''not'' specify the bit patterns for single- and double-precision floating-point numbers in a way that this report seems to think can be exploited in bytevectors.

 * The problem of two record systems that don't quite work together.  See Will Clinger's essay [http://www.ccs.neu.edu/home/will/R6RS/essay.txt "Fixing the Syntactic Record Layer"].

 * You cannot simply take a record value and access one of its fields by name.  See [http://lists.r6rs.org/pipermail/r6rs-discuss/2007-August/thread.html#3145].  We want a container that requires certain behavior of the values it contains while not requiring that theybe on an approved list or inherit from the same ancestor.  Importing the accessors of each type of value we wish to contain makes the container's import list the approved list.

 * All condition types should be record types, and compound conditions should be eliminated.

 * R6RS gives a fairly low priority to backwards compatibility.  Implementations are evidently expected to provide mechanisms for switching.  There's no incremental update path; each Scheme program must be completely transformed all at once, which effectively means it will never happen.

 * Modules and `syntax-case` are entirely new and declarative sub-languages fundamentally different from the core language, which has always been imperative. 

 * The module system is basically a way to tell the linker how to construct programs from parts.  Rather than invent a new language to do this, it's possible to build the linker such that the programmer can insert Scheme code to control aspects of the linking process.  Such code could do ''more'' than the current module system does, and because of the added expressivity, it could do so more concisely in many cases.

 * The `syntax-case` system implements a term-rewriting system, with limited programmability, to solve a problem for which there are significantly simpler solutions.  This sub-language introduces a new kind of variable that behaves differently from the variables we're used to, and pushes pattern-matching and templating to the center of the macro-writing process.  

 * The effort required to implement a standard-compliant Scheme becomes much larger than before.  This will discouraging future implementors, endangering the diversity that is one of Scheme's present strengths 

 * Immutable pairs may make optimization easier, but do not fit at all with the practice and spirit of Lisp.

 * It has been clearly shown that `dynamic-wind` (and R5RS `call/cc`) is implementable in terms of R4RS `call/cc`, but that the reverse is not true. Given the renaming facilities available in the library system, it would seem ''really'' obvious that R4RS `call/cc` should be in the core and R5RS `dynamic-wind` and `call/cc` should be a separate library.

 * The exception/condition functionality ''should'' be part of the core specification - as is shown by the inclusion of a section on exceptions in the formal semantics.

 * The Scheme specification needs a solid model for asynchronous events. 

 * There is no convincing evidence of the value of supporting Unicode for program text. That said, the capability of S-expression `read` makes it hard to avoid. The addition of Unicode escapes is ugly.

 * Multiple-return values *still* has not been fixed. The most straightforward solution is simply to make all continuations multi-valued - or rather that applying a single-argument continuation to multiple values results in the coercion of the actual arguments to some list form.  It would actually be even better to eliminate multi-valued continuations entirely, but that would be at the cost of breaking existing code (SRFI code even).

 * A petty irritant for me is the official sanction of square brackets: they are ugly and unhelpful in reading code. They create a very discordant visual rhythm and should be summarily outlawed. Square brackets are a gross violation of the LISP Party Ethic and offending implementors shall be required to submit thorough self-criticism of their motivations and then will be summarily shot. I really mean this.

 * R6RS tries to standardize insufficient compromise solutions for things that are better left unspecified.  R6RS is a misguided attempt to make Scheme more suitable for the mainstream, but effectively does the very opposite by removing the assets that always distinguished Scheme from other dialects: smallness and simplicity.

 * The reason for ABSOLUTELY prohibiting linking to multiple versions of the same library per formal comment 130 is very weak.  Scheme and the LISP family in general are incisive, powerful languages that give their users great power that can be easily misused.

 * Scheme should accommodate the desires of library writers to intermix definitions and expressions [insert usual platitudes about needless restrictions---and how Scheme is perhaps more than anything else a system for communicating to other programmers...].  

 * If R6RS fails, the next attempt should be ''in the direction'' of previous revised reports in requiring unanimous consent ''for the core'' (which includes the library mechanism, but precious few libraries).  Therefore the process in the future must continue to require super-majorities for core ratification and maybe even greater ones than the current 60% -- and that helps to properly draw the line between it and the required standard libraries.  Library ratification does not need to be as strict: as long as they are "acceptable" and have nothing dreadfully wrong with them, it is better to have usable standards than no standards at all, and in theory the SFRI process has allowed the community to discover what works in practice and it worth standardizing.

 * It is perhaps better to remove those features of R5RS that prohibit Unicode implementation (such as `char->integer` and `integer->char`), and rely on extended SRFI-13 and SRFI-14 for Unicode support.

 * The core language must only include the abstract vector type. Having particular types of vector representations is precisely the domain of SRFIs. The R6RS proposal byte vector syntax is not widely agreed upon, and it requires two sets of vector procedures in the core language. 

 * The core specification must not mandate any particular standard for dictionary structures, as the existing implementations vary widely in APIs. A side effect free association list structure may be permitted, but anything more sophisticated must be relegated to a library. 

 * The R5RS report used the phrase "an error is signaled" to indicate that implementations must detect and report an error, without going into specifics. In contrast, the R6RS proposal requires the signaling of exceptions, and it goes further to propose a complex and very specific hierarchy of exceptions. Once again, common practices in the Scheme community are ignored, and instead of relying on the SRFI process, exceptions are mandated in the core language.

 * The enforced phase separation in the module system described in the R6RS proposal overspecifies the module system and disallows different implementation strategies, thus prohibiting the Scheme community from experimenting and innovating.  In addition, the module system becomes an obstacle to the use of Scheme as a teaching language, because beginners now must deal with it long before it can be explained to them why

 * Library descriptions need to be enclosed in an additional layer of parentheses, as opposed to a single definition at the top of the file.

 * All but fundamental I/O primitives should be put in a library: non-abstract operations do not belong in the core language. 

 * The Scheme community relies in considerable part on the efforts of individual developers, or small teams of developers, who have to implement these reports -- or who would presumably like to do so if it did not take forever.  I think the Scheme community would be better served by a much smaller language, whose features included the minimum necessary so that the language could easily be extended by loading Scheme source code itself (and perhaps compiling it).

 * The current thrust of Scheme development raises a concern that the language will go the way of C++, which seems to have given rise to a large variety of mutually nearly incomprehensible C++ dialects and programming styles, and to a great deal of confusion about what the various features are supposed to do:

 * We want to experiment and innovate, and the purpose of standardization is the exact opposite: to prevent experimentation and innovation. The objective of standardization is to get it right on the first try, to allow long term stability and interoperability, when the benefits of such outweigh the benefits of innovation.   Almost all of us in the Scheme community would love for Scheme to catch on in the mainstream.  Some people believe that the only factor that prevents this from happening is standardization (of a big language). Thus they advocate adoption of R6RS.  But Scheme occupies a unique niche which would be compromised thereby.

 * The goal in R6RS should be to make it easier to achieve conformance ''and'' easier to experiment without getting the pedants' backs up. A good standards document helps the documentation effort.  R6RS achieves none of the goals mentioned above.

 * R6RS will likely create a schism between the various scheme implementations, because it ignores the desires of parts of the community, in order to cater to some others. Scheme can't operate under the assumptions of one-size fits all, because the Scheme community is naturally already heavily invested in areas where divergence (to some degree) is encouraged. 

 * The operational semantics for the proposed R6RS is nowhere near as clean and succinct as the denotational semantics for R5RS. Considerations of their non-normativeness aside, the denotational semantics presented, in a couple of pages, a clear formalization of the basis of Scheme.

 * R6RS simultaneously breaks with the Scheme tradition to favor homogeneity and software-engineering appeal and still doesn't go far enough towards becoming a useful engineering tool. 

 * The record system is far too complicated.

 * Hash tables, while useful, are not necessary (after all, other equally useful data structures were not added); rules regarding things like square brackets should not exist, even in non-normative appendices

 * The `when` and `unless` forms should not be specified.

 * Exceptions are an unfortunate (if understandable) addition.

 * I can't predict based on principles why `assoc` and `memq` (for example) are exiled to 'libraries' without bringing along the equally derivative `append`, `string-for-each!`, `vector-map`, and so on; the library system fails to delineate a kernel, which I had thought was one of its goals.

* Why would one aim to nail down so many boundary conditions without also specifying order of argument evaluation?

 * The jump from R5RS to R6RS is too big for its users (implementors and other programmers) to digest all at once, and has not set a good example for R7RS.  To make sure we all continue communicating and learning from one another, the revision process needs to be more open and incremental in the future, I think.

 * Strings always were a bit sore in Scheme, with their manifestly-typed locations.  Instead of solving that, this draft adds bytevectors.  Neither can contain variables in the right-hand side of a syntax rule - the kind of arbitrary restriction of which Scheme should be free.

 * The draft recognises libraries, a top-level and scripts, three variants of what is basically the same thing (see Queinnec&Padget: ''Modules, Macros and Lisp'') - not the Scheme way.

 * R6RS moves away from the ability to be used interactively through a REPL by removing `load` and offering only a     static linking model for programs.  It does not explain how this affects program development and debugging using a REPL, which is the bread-and-butter of a large number of Scheme users.

 * Several features specified in R6RS have been tested in existing implementations of Scheme insufficiently to warrant inclusion in the standard.  Some features of the draft, such as the I/O system and records, are completely new and clearly suffer from feature creep.  The standard is not the place to experiment.  

 * R6RS puts too much emphasis on performance.  Is R5RS Scheme so slow that we need to introduce into the standard immutable variables, fields, and pairs?  I am all for speed, but not at the expense of inconsistencies in the language design.  Immutability hinders debugging and "live-repair", and goes against the basic design principles of Scheme:

 * Given that the draft requires the full numeric tower and bignums, and that fixnum and flonum types have implementation dependent ranges, there is no need to require fixnum and flonum types in the standard.

 * Scheme needs a simple module system that can be grasped easily.  Scheme can live with the R5RS hygienic macros for a while still.

 * Many R6RS features are useful and definitely should be part of the standard, but rather than arbitrarily including them in the language, the should be defined ''on top of the language''.  Only features that are required in order to support the libraries should be carefully added to the language itself.  This approach would lead to a ``core language'' and a set of ``extension libraries'' that is implemented in terms of the core language. These libraries should be optional extensions to the core language.

 * The innovations of the draft fall into essentially two pieces.  The first is a syntax for defining and importing identifiers from "top-level libraries".  The second is the addition, through the library mechanism, of a variety of data types and attendant functional and/or syntactic interfaces.  While both of these are useful for general programming, I do not believe either of them deserve a place in the Scheme language standard.

 * R6RS utterly neglects the notions of "top-level program" and "top-level environment", which are absolutely fundamental to Scheme as a language and a system.

 * Far too much of R6RS appears fixated on defining and punishing syntactic errors.

 * Scheme is best served by retaining its jewel-like character: tiny, beautiful and perfect.  There is no need to expand Scheme as the editors propose -- if I want Common Lisp, I know where to find it.  I favor only a very small expansion of Scheme to add a module system that enables numerous other extensions to be added without conflict.

 * The full numeric tower should be required, because some small and specialized implementations of Scheme may find that the full numeric tower conflicts with their other priorities.

 * There are competing character sets that may be preferable to Unicode in some circumstances, and requiring unicode would forestall their use.  Unicode necessarily requires more storage space than ASCII, and more complicated runtime support, which may not be desirable in all cases.  

 * R6RS mandates too much.  The editors seem to be concerned that there is too much variety in the Scheme world, and propose to eliminate it by making the rulebook thicker.  That is exactly the wrong approach.  Celebrate the variety, and encourage it, so that Scheme implementations can make their own decisions about what is important to them.

 * The only change needed for a new Scheme standard is a simple module system that permits users to extend their Scheme systems cleanly.  The module system should do for macros what lambda does for functions: permit macros to be visible only within a limited portion of a program.  There is no need for the complicated module system the editors propose, and especially not for built-in versioning.

 *  It would be regrettable if something becomes a standard because "we didn't have  time to come up with a better one by the last couple of days".

 * Despite the last-minute change in the 5.97 draft that attempted to fix things by piling yet another feature, a parent-rtd clause, on top of the syntactic layer, you ''still'' have to know whether the base record type was defined using the syntactic or record layer, and you ''still'' can't change a record definition from one layer to the other without running the risk of breaking client code.

 * Record types defined by the syntactic layer are not interchangeable with record types defined by the procedural layer.

 * In consequence, the code you write for a record type definition that inherits from some base type depends upon whether that base type was defined using the syntactic or procedural layer.

 * Both layers are complex, which makes it hard for a casual reader to understand their relationships.

 * The record procedural layer is the more expressive layer, so the draft's new warnings that try to frighten programmers into preferring the syntactic layer would have limited impact even if they were true.

time

2012-02-08 14:56:40

version

1