ERR5RS:SRFIs and Standard Libraries
From SchemePunks
Contents |
[edit] SRFIs and Standard Libraries
This is an extremely tentative list of things to do. The main reasons for writing it down are to give some idea of the potential scope of the ERR5RS, and to provide a focal point for discussions of that scope.
[edit] General Principles
The essential component of ERR5RS is dynamic loading of libraries. If that component is successful, then specific libraries can be described by SRFIs.
In general, controversial libraries should not become an essential or required component of the ERR5RS. This ideal may be compromised when there is obvious need to standardize some capability that can be provided by any of several competing approaches, all of them controversial, but the ERR5RS should not stray from this ideal without compelling reason. When in doubt, leave it out.
The SRFI process works well for developing and publishing APIs.
The SRFI process has not worked so well for publishing reference implementations. In most cases, the reference implementation has been included within the SRFI document itself, and has been frozen when the SRFI attained final status. That has made it impossible to fix bugs or to improve the portability or to add critical new features to a reference implementation without creating a brand new SRFI for that purpose.
The Snow project, or something like it, might provide a better way to publish both portable and implementation-specific implementations of ERR5RS libraries.
[edit] Essential or Optional?
The ERR5RS should specify the set of essential extensions that all implementations of the ERR5RS are expected to provide, so programmers will know what features they can use when writing fully portable ERR5RS code.
The ERR5RS may also specify optional extensions that implementations of the ERR5RS are encouraged to provide. Programmers may use these optional features when writing conditionally portable ERR5RS code that should run in any implementation of the ERR5RS that provides the specific optional features that are used.
The ERR5RS should also allow implementations to provide extensions that are not anticipated or explicitly sanctioned by the ERR5RS. Nonstandard extensions are nonportable by definition, but the ERR5RS should not try to prevent new de facto standards from emerging, nor should it try to punish early adopters who promote extensions that have not yet been blessed by some arbitrary supermajority of some arbitrary standards process.
Experience with the R5RS has demonstrated the need for greater standardization of a few key features: lexical syntax, libraries, records. These should be essential features of the ERR5RS. To improve code sharing and reuse, these essential features should consist of a proper subset of the corresponding features of the R6RS and/or popular SRFIs. (This is just barely possible for records, since the R6RS is gratuitously incompatible with the relevant SRFIs.)
Experience with the R5RS has also demonstrated the desirability of various features that needn't be supported by all implementations but are used by enough programs to justify optional status. Standardization of these features promotes conditional portability and reuse. Most of these optional features are best described as SRFIs but some things, such as the semantics of arithmetic on complex numbers with exact or inexact rational components, belong in the ERR5RS.
[edit] Naming of Libraries
The essential libraries of the ERR5RS should be named in some systematic way. For example, the essential record library of the ERR5RS might be named (err5rs records procedural).
Optional libraries that provide a proper subset of some standard R6RS library should also be named similarly, e.g. (err5rs io ports). This naming convention would encourage R6RS programmers to use the corresponding ERR5RS library instead of R6RS standard libraries. That practice would improve the portability of R6RS code by promoting code sharing and reuse between traditional and R6RS-style programs.
[edit] Specific Libraries
This is a straw proposal.
The essential ERR5RS libraries might consist of:
- (err5rs), which might consist of all R5RS procedures plus the ERR5RS library API. It might add a few more things, such as the R6RS div and mod, and it might leave out a few things, such as values and call-with-values and/or delay and force.
- (err5rs records procedural), whose design is likely to be at least a little controversial, but it would be hard to do this much worse than it was done in the R6RS.
Some of the optional ERR5RS libraries that would be possible:
- (err5rs load), for dynamic loading of ERR5RS code, including libraries.
- (err5rs records syntactic), whose design is likely to be at least a little controversial, but it would be nearly impossible for us to do this as badly as it was done in the R6RS.
- (err5rs unicode), which might consist of the corresponding R6RS library less char-titlecase and char-foldcase.
- (err5rs texts), which would introduce a new data type of immutable Unicode texts. (Several R6RS programmers and implementors have already expressed interest in such a thing. Publishing it as a SRFI with an ERR5RS library as its reference implementation would increase the visibility and establish the importance of the ERR5RS.)
- (err5rs bytevectors), which might be a proper subset of the corresponding R6RS library, certainly omitting the endianness syntax.
- (err5rs lists), which might consist of SRFI-1 with some minor omissions and/or tweaks.
- (err5rs sorting), which might be identical to (rnrs sorting (6)).
- (err5rs records inspection), which might be a proper subset of the corresponding R6RS library.
- (err5rs io ports), which might resemble a proper subset of the corresponding R6RS library, but should omit about half of it.
- (err5rs files), which might be a proper superset of the corresponding R6RS library, adding list-directory and perhaps a few other things that are already in fairly widespread use.
- (err5rs arithmetic fixnums), which might be a proper subset of (rnrs arithmetic fixnums (6)), probably with some relaxation of semantics to remain more consistent with R5RS philosophy and practice.
- (err5rs arithmetic flonums), ditto mutatis mutandi. (Alan Watson, Brad Lucier, and Aubrey Jaffer would know more about this stuff than Will Clinger does, although he's always willing to argue with anybody.)
- (err5rs arithmetic bitwise), ditto mutatis mutandi.
- (err5rs syntax-case), which Andre van Tonder should write up as a revision of his previous SRFI.
- (err5rs hashtables), which could be a proper subset of the corresponding R6RS library, which has several genuine advantages over SRFI-69.
- (err5rs include), which would implement syntax to interpolate source files.
