This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home. For a version of this page that may be more recent, see WG1ReBallotGleckler in WG2's repo for R7RS-large.


2010-10-31 14:03:39
13Revised voted on #2 Module System.history

Notes about results:

WG1 Ballot Items To Finalize By Oct. 31

WG1 - Modules

#2 Module System

As per the charter, we need a module system proposal which allows sharing of code between implementations.

This is one issue where we can't default to the R5RS, since it has no module system. If we can't come to consensus, we will have to take the R6RS module system as-is.

Note the r6rs-- option is just the R6RS module system without versioning or phasing.

I've changed my top preference to ModulesShinn for two primary reasons: 1) It is a compatible subset of R6RS, with two syntactic differences that should be easy to implement, so it should be easy to use R6RS libraries that only make use of its subset of the R6RS module system; and 2) it includes the include form, allowing code to be separated from its library specification, which makes it easy to use code that is intended to be loaded at top level, e.g. in R5RS implementations, eliminates unnecessary indentation, and feels more compatible with interactive development.

WG1 - Core

#57 Simple randomness

Student programs often want a small amount of randomness, not necessarily of very high quality. Shall we provide a simple interface to a random variables in WG1 Scheme?

RandomCowan does not allow control over the seed, so it is of such limited usefulness as to not be worth including. The API defined by SRFI 27 does allow control of the seed, and makes random sources first class, both of which are good ideas. However, the API is awkward, especially random-source-state-ref and random-source-state-set!. I'd like to see WG2 do a survey of existing implementations and find something better than both of these proposals.

WG1 - Exceptions

#18 Exception System

R6RS provided a detailed exception system with support for raising and catching exceptions, using a hierarchy of exception types.

Do we use this, or parts of it, or a new exception system?

While the R6RS exception system is not perfect, I'm happy with it. In WG1, it belongs in a module, not in the core.

If we don't agree to use the R6RS system, then I'd rather see WG2 refine it instead of including ExceptionHandlingCowan in WG1, since the ExceptionHandlingCowan proposal doesn't explain the rationale for its deviations from R6RS. I've studied the mailing list archive and can't find a convincing argument for ExceptionHandlingCowan, either, so I'm sticking with R6RS or, as a fallback position, WG2.

The largest flaw I see with the R6RS condition system is that its condition taxonomy is too coarse and focused on operating-system issues. Compare it with the taxonomy of Gambit or MIT Scheme, for example. (See ExceptionTaxonomies for details of the condition taxonomies of many Scheme implementations.)

Some people have proposed taking the R6RS exception system but not its condition taxonomy. If we do, I hope we'll still standardize on some taxonomy rather than none. Without a common taxonomy, it's hard to share code.

WG1 - I/O

#52 read/write cyclic data

SRFI-38 standardizes the #0=(1 . #0#) shared structure notation for read/write. In the case of write, this can be expensive to compute, but otherwise the common case of the repl printing a cyclic structure results in an infinite loop.

Do we want to add support for this, as an option or separate set of procedures?

srfi-38 for separate procedures or native to require read and write to handle cyclic notation.

SRFI 38 supports this notation, but doesn't require that read and write support it, so writing doesn't have to become more expensive. Since many programs won't need this feature, it belongs in a module.

WG1 - Macros

#8 SRFI-46 ellipse specifier in syntax-rules

As an alternative to #7, SRFI-46 proposed allowing an optional ellipse specified as an identifier before the literals list in syntax-rules:

(syntax-rules ::: () <ellipse now represented as ::: instead of ...>)

Do we allow this?

#9 tail patterns in syntax-rules

SRFI-46 and R6RS both allow a fixed number of tail patterns following an ellipsis in a syntax-rules pattern:

(P1 ... Pk Pe <ellipsis> Pm+1 ... Pn)

R6RS further allows dotted tail patterns

(P1 ... Pk Pe <ellipsis> Pm+1 ... Pn . Px)

where Px only matches a dotted list.

Do we allow either or both of these extensions?

I don't feel strongly about this issue, but the extensions seem harmless.

WG1 - Numerics

#22 mantissa widths

R6RS introduced the concept of mantissa widths as an alternative to the R5RS #s in numbers. Do we want either or both of these?

I don't have a good enough understanding of the importance of this issue to have a strong opinion, so I'm following GJS, who is of course a great mathematician and programmer, and have chosen "both" as my first preference.

WG1 - Reader Syntax

#11 case-sensitivity

Does the reader fold case by default, and if so how?

Yes to fold-case (R5RS) no to preserve case (R6RS), additional votes to come later from specific proposals.

#14 alternate comment syntax

R6RS provides support for #; nested sexp comments, and #| ... |# nested block comments. Do we include either or both of these?

WG1 - Strings and Chars

#26 string normalization

R6RS provides procedures to explicitly convert strings back and forth between the four Unicode normalization forms.

The previous phrasing of this option was overly vague, referring to "any form of normalization." I've had to treat yes votes as undecided for lack of a better default. If you voted yes before please choose one of the following options or write in your own proposal.

Note UnicodeCowan currently provides specific normalization procedures.

The complexity of Unicode should be, as much as possible, banished from WG1. If it is included, however, I'll follow John's lead, since he is a Unicode expert, and vote for specific/module.