ERR5RS:Artifacts
From SchemePunks
Contents |
[edit] ERR5RS Artifacts
If successful, ERR5RS will involve the creation of several concrete artifacts, and may involve the development of several others. These concrete artifacts may include:
- wiki pages
- SRFIs
- SRFI 7 feature identifiers
- reference implementations
- programs written to ERR5RS specifications
- implementations of ERR5RS
- a distribution mechanism for portable ERR5RS libraries
- a revision of the R5RS, possibly as ERR5RS
- a revision of the R6RS, possibly as R7RS or R8RS
Each of these is discussed below.
At present, these discussions are just my musings. Please improve. (Wclinger 14:12, 23 September 2007 (PDT))
[edit] Wiki Pages
Wikis enable a group of like-minded people to make written, documented progress toward a common goal.
Wikis are not so good at resolving disputes between people whose goals are incompatible, but the goals of ERR5RS are fairly clear, limited, and highly constrained. Those who do not wish to achieve the goals of ERR5RS will make more productive use of their time on other projects. As a self-selected group who agree upon these requirements and goals, we are likely to make good progress toward those goals by constructing these wiki pages, and we have already made a good start.
Although the organizers of this site have suggested that wiki pages can be frozen once the project is complete, the wiki itself provides no natural process for deciding when its wiki pages are complete. By nature, language standards are never complete, so processes for declaring them complete are inherently unnatural and often divisive. We can discuss those processes on the wiki, and may even arrive at some consensus about them, but ERR5RS itself might ultimately take the form of documents that are more static and formal than wiki pages.
[edit] SRFIs
SRFIs have a formal structure and an established process that has earned the respect of the Scheme community.
No single SRFI with the scope of ERR5RS has ever been proposed, but individual components of ERR5RS will be comparable in scale to some previous SRFIs, including (but not limited to) SRFIs 1, 4, 9, 13, 14, 23, 43, 45, 47, 52, 56, 57, 60, 63, 66, 68, 69, 70, 72, 74, 75, 76, 77, 81, 83, 85, 91, 93, and 95.
The SRFI discussion process includes public review by a (potentially) larger number of experienced programmers and implementors than are likely to participate in the ERR5RS process. Publishing ERR5RS components as SRFIs would improve the technical quality of those components, and would also advertise ERR5RS to the community at large.
Each ERR5RS SRFI will be written by some proper subset of the people who have developed ERR5RS, and will have authority to describe whatever component is specified by their SRFI. If the authors of some ERR5RS SRFI go so far wrong that their mistakes cannot be corrected during the public review, then another group of authors can write a different ERR5RS SRFI that does a better job of specifying the component. We hope this won't become necessary, but if it does then we can trust implementors and users to identify the better SRFI.
One shortcoming of the SRFI process has been the coupling of SRFIs with specific reference implementations. Since those reference implementations are frozen when the SRFI is frozen, many are now obsolescent or obsolete, and some have always contained serious bugs that cannot be corrected without submitting a new SRFI. Although we aren't likely to talk the SRFI editors into decoupling SRFIs from their reference implementations, we can and should decouple ERR5RS reference implementations from ERR5RS SRFIs by establishing separate repositories for ERR5RS reference implementations, regarding the reference implementation that becomes part of the final ERR5RS SRFI as a mere snapshot of one of the reference implementations in one of the ERR5RS repositories.
At this writing, it is unclear whether the SRFI editors will accept reference implementations that use ERR5RS or R6RS features. If we can use ERR5RS and R6RS features, then many of the ERR5RS SRFIs will have very succinct reference implementations. If we have to stick to the R5RS features, or to R5RS features with minor extensions, then some of the reference implementations will be rather large.
[edit] SRFI 7 feature identifiers
One of the advantages of using the SRFI process to describe ERR5RS components is that these components will thereby acquire a SRFI 7 feature identifier that implementations can use to advertise the fact that they support ERR5RS, and that programmers can use to make conditional use of the ERR5RS component. This will be especially important for optional components of ERR5RS.
[edit] Reference Implementations
Reference implementations of ERR5RS components reassure both programmers and implementors that the component is feasible, make it possible to experiment with the ERR5RS component in systems that don't yet provide it natively, and can make it much easier to implement ERR5RS.
For example, Andre van Tonder's reference implementation of R6RS libraries and syntax-case is the key component of Larceny's R6RS-compatible mode, and (if the R6RS is at all successful) will likely be used in most other implementations of the R6RS. A revision of van Tonder's reference implementation is likely to become the key component of most implementations of ERR5RS.
Lexical syntax and records are two other ERR5RS components for which reference implementations are critical to the acceptance and implementation of ERR5RS.
These reference implementations should be hosted (and updated) at one or more ERR5RS sites. Larceny's Trac site ( http://larceny.ccs.neu.edu/trac/ ) and the Snow site ( http://snow.iro.umontreal.ca/ ) are two possibilities, but hosting reference implementations at the wiki site would make it easier for any programmer to modify the reference implementations. (We can discuss whether that would be a feature or a bug.)
[edit] Programs Written to ERR5RS Specifications
ERR5RS will be successful only if it helps programmers to write useful programs.
[edit] Implementations of ERR5RS
ERR5RS will help programmers to write useful programs only if there are good implementations of ERR5RS.
If ERR5RS is at all reasonable when judged by its current requirements and goals, then it will be implemented in Larceny. Other implementors, having seen what happened with the R6RS, are unlikely to commit themselves until they see how ERR5RS turns out. If we do a good job with the design of ERR5RS, however, then there are likely to be several good implementations of it.
[edit] Revision of the R5RS
ERR5RS is a revision of the R5RS, but whether it should take the form of an R5RS-like document is an interesting question that depends in part upon its reception by programmers and implementors.
If ERR5RS is welcomed and implemented, and becomes an important de facto standard, then it should be described by a formal document that can take its rightful place alongside other de facto standards such as the R5RS.
If ERR5RS is implemented only by Larceny, then a formal description of ERR5RS should become part of the Larceny documentation but would not have stature approaching that of the R5RS.
Will Clinger expects to produce a formal draft of ERR5RS in collaboration with others who are willing to work on the thing and have proved their ability to write accurate technical prose. At the very least, this document will become part of the Larceny documentation. If ERR5RS is successful, then this draft may become the basis for some formal document that will be used by other implementations and can be ratified by users of ERR5RS.
As has been seen, however, the creation of a ratification process is fraught with pitfalls. For the moment, we should concentrate on the specification itself. It is better to create a successful but unratified standard than to create a ratified but unsuccessful standard.
[edit] R7RS or R8RS
If ERR5RS is successful, then it is likely to have some influence on successors to the R6RS. The extent of its influence depends partly upon the direction taken by the Scheme Language Steering Committee that devised the R6RS process, but it also depends upon matters over which we can exert some control: the technical quality of ERR5RS and the extent of its adoption by implementors and programmers.
