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 WG1Ballot2Results in WG2's repo for R7RS-large.

WG1Ballot2Results

cowan
2012-04-04 10:13:12
2history
source

Notes about Results

See WG1BallotExplanation.

Instructions

WG1 Ballot Items To Finalize By Jan. 9

WG1 - Core

#32 user-defined types

Do we support any means of creating disjoint user-defined types, such as in SRFI-9, SRFI-99 or the R6RS record system?

Cowan
I had a lot of trouble with this one. Srfi-9 has lots of existing use and is the nearest thing to a standard we have. On the other hand, my idea is small and can be more efficient than plain vectors, because it doesn't need a bounds check and a type check, just a type check.
Gleckler
I had initially voted for SRFI 99 as my top choice, but I'm now convinced that that's just too complicated a system for core Scheme. We need something more fundamental upon which other systems can be built. SRFI 9 is widely used and is about the simplest syntactic implementation one could hope for. However, it doesn't support inheritance. RecordsArcfide is also simple and it supports inheritance. It is a syntactic system. RecordsCowan is also simple and also supports inheritance. Furthermore, it's a procedural system, which makes more sense as the fundamental approach for WG1, which should be about nailing down simple, clean design for the core ideas. UniqueTypesSnellPym is a good distillation of the core ideas and is also procedural. However, its handling of subtypes (i.e. the requirement to pass <e> and <d> procedures rather than the supertype itself) and the way that fields are declared to be mutable are both awkward. However, I do agree with the premise stated in the Background section, i.e. that we should provide a mechanism on which other, more powerful and more widely adopted record systems can be built. AggregatesMedernach is another good distillation of the core ideas. However, constructing its aggregate functions is an all-or-nothing affair; the type switch mechanism seems to require complete destructuring of the record even when not all of the components are necessary, e.g. in the SRFI 9 predicate example; and there is no inheritance. SRFI 99 (ERR5RS Records) is an extension of SRFI 9 that is a rationalization of the R6RS system, so I'm voting for it ahead of the R6RS system. As the description says, "This entire SRFI is compatible with the procedural and inspection layers of the R6RS record system, but offers several worthwhile improvements over the R6RS system." Here is exactly how I came up with the preference order above: cowan > snellpym+inheritance+mutate because <cowan> is simpler and cleaner snellpym+inheritance+mutate > medernach snellpym+inheritance+mutate > snellpym+mutate hsu > srfi-9 because inheritance is desirable medernach > hsu snellpym+inheritance+mutate > hsu snellpym+mutate > hsu because procedural is more fundamental than syntactic srfi-9 > wg2 hsu > wg2 because WG1 Scheme should have some form of record definition facility wg2 > srfi-99 because of the high complexity of SRFI 99, as well as the problems others have reported srfi-99 > r6rs because SRFI 99 is a refinement of R6RS records, designed to solve some of their problems wg2 > r6rs because of the high complexity of R6RS, as well as the problems others have reported r6rs > snellpym because snellpym doesn't support mutation
Medernach
IMHO Core Scheme should have the ability to create disjoint kind of data, this is the essence of data types. On top of that capability the various kind of records could be build. I don't think much more is needed inside the core, let other features be for WG2. SRFI9 is nice but I am a bit afraid about its real extension potential to make it part of WG1 standard. UniqueTypesSnellPym proposal is in the spirit of this, however I dislike to select fields by numbers and the list of flags for mutation looks hairy to me: it means for instance that I have to know the number of fields of the parent type, even worse: adding a field in a parent force to shift all the hierarchy of subtypes, this is too much tight together. Instead of a list of flags my proposal allow to have all fields mutable and controlling mutability by exporting with a module system only what mutators I allow to use. Update: I overtook that RecordsCowan inheritance is based on field numbering. Then there are the same problems than in snellpym+inheritance. However it is a nice and simple proposal but I prefer widespread SRFI-9 over it (no inheritance than number-based inheritance).
Shinn
I think providing a syntactic interface as the basis for records is more widely supportable and may offer better optimization chances, however the SRFI-99 API is too difficult to remember and RecordsArcfide seems only partially better, so I prefer the de facto standard SRFI-9 for WG1.

#50 byte-vectors

Several SRFIs, R6RS, and most Scheme implementations support some sort of uniform packed integer vectors. In particular, these are necessary for efficient binary I/O, and for memory mapping, so WG2 will certainly want them.

Do we provide a syntax and basic API for these in WG1?

Gleckler
Reviewing the proposals again and taking a look at other people's votes, I'm now convinced that the <cowan> proposal is better than <r6rs>. That's primarily because <cowan> makes endianness a property of each accessor and mutator procedure rather than a parameter, which means that efficiency through inlining is even easier to achieve. However, I still prefer the term "byte vector" to "blob." We should specify what Unicode procedures are required, if any, when the Scheme implementation doesn't support Unicode. Once again, though, it would be great if people writing proposals specifically justified their design decisions in the text of their proposals, particularly when deviating from existing Scheme standards. That would make voting much easier.
Harvey
But I'd really like a better name than "blob"!
Hsu
R6RS has a clumsy interface that is corrected, IMO, by Cowan's proposal.
Lucier
I prefer "full cowan", what he's recommending for WG2.
Shinn
I like the idea behind snellpym but it needs work - I'd rather give the author time to flesh it out. Failing that, I don't see what differentiates BlobAPI from the R6RS bytevectors.

#55 Lazy evaluation

R5RS provides a simple mechanism for easy cases of lazy evaluation. It does not support generalized lazy evaluation, because all built-in procedures are eager whether they 'need' to be or not. The relevant identifiers are delay and force; they are not present in IEEE Scheme. SRFI 45 argues that this pair is insufficient for expressing common lazy algorithms in a way that preserves tail recursion, and adds lazy (equivalent to (delay (force ...)), but acting atomically) and eager. The semantics of delay and force remain downward compatible.

Vote srfi-45 to add just the bindings lazy and eager in addition to delay and force, not all of the srfi-45 utilities. Vote none to remove delay and force from the standard.

Cowan
I find the arguments found in SRFI 45 itself compelling: with lazy, it becomes possible to mechanically change ordinary eager expressions into lazy ones mechanically. Using delay causes a failure of tail recursion.
Gleckler
As Alex has said in his message item #55 - I'd rather be lazy than eager with new primitives, there hasn't been enough discussion of or experience with SRFI 45 to justify its inclusion in WG1 Scheme.

#57 Random Numbers

Random numbers are useful for a wide variety of applications, including cryptography, statistics, games, simulations and genetic programming. Do we want to provide an interface to random number generation in WG1 Scheme?

Cowan
The CL system has been around for quite a while, and seems to suit. The implementation gets to pick an appropriate algorithm for its situation. Srfi-27, with its fixed implementation, makes more sense as a library. I voted against my own idea here.
Gleckler
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. The Common Lisp-based proposal is the best developed of all of these.
Hsu
I tend to think that CL is okay here, but absent that choice, a simpler approach that is flexible is preferable.
Lucier
I don't think we should be trying to provide randomness for cryptography applications, it's too hard (meaning, I don't understand how to do it ;-). I thought originally that SRFI-27 would be good because it has a good base generator in its default implementation and a good interface for getting random integers and reals. However, RandomnessCommonLisp provides an interface that may be a better starting point for what we want. I'd like to separate the generation of inexact and integer random numbers, and also to provide (random-source-later-stream random-source [optional-index]) and (random-source-later-substream random-source [optional-index]), which would provide a basis for applications in "statistics, games, simulations, ... genetic programming" and the other simulation-type applications.
Medernach
This is really a module issue, let people choose among a set the one which fits the best their needs. Standardize names only for helping code reuse. By the way if one need repeatability why not roll their own random stream from a saved persistent table ? (as good old random number tables one could buy for those who knew about it :)
Radul
If you can't do it right, don't do it at all. Unlike a module system, randomness can be retrofit at user level, so Scheme will not shrivel up and die if we wait for perfection.
Sussman
Do not introduce anything "not necessarily of very high quality" into the language! Don't do anything that Knuth and Kahan would not approve of! If you have good integers and assignment a user can make his own, so this is not essential.

#62 Environment Variables

Currently, there is no standard way to communicate with the context from which a Scheme program was started. This has become pretty standardized over time: a list of strings ("command-line arguments") and a map from strings to strings ("environment variables") on input, and a small integer or string on output ("exit value"). Scheme should recognize these realities.

We have command-line and exit from ModulesShinn, so the question remains if we should add SRFI-98 environment accessors.

Cowan
Most programming environments can supply these, and programs should have easy access to them. Putting them in a module makes them optional for small Scheme implementations that can't support them. Command-line and exit should go in the same module.
Ganz
Yes, a must-have.
Gleckler
This shouldn't be included in WG1 Scheme except as a module. Environment variables, while common, are operating system specific. Embedded systems are unlikely to have them.
Medernach
This should not be enforced, as embedded devices don't need it. Providing it as a module is a good choice.

#68 "Undefined value" vs. "undefined values"

In R5RS, many procedures and syntax forms return an "undefined value". In R6RS, the corresponding convention is to return "undefined values", meaning an undefined number (including zero) of undefined values. How shall R7RS go?

Vote r5rs for a single undefined value, r6rs for zero or more undefined values, or zero for exactly zero values. Anything other than r5rs would break R5RS (and IEEE) compatibility.

Cowan
R5RS, reluctantly. I really don't think it would in practice break compatibility, because in practice Scheme implementations are okay with handling multiple values in begin forms and the equivalent.
Ganz
This seems much more elegant -- as long as we've got multiple values, use zero of them.
Medernach
What is the rationale behind this ? Is it to allow partial functions returning an <undefined> value and to propagate it ? Then IMHO the best semantic is to return empty value. Update: I am now convinced that R6RS phrasing is the more flexible option. However I exhort using "(values)" whenever possible.
Shinn
Too many existing programs expect exactly one value.
SnellPym
"exactly zero" undefined values is just plain arbitrary and therefore sucks. An undefined number allows for future expansion, compatibly.

#49 Undefined value API

Assuming a single "undefined" value (dependent on the result of #68), users sometimes want to test for this value. If we enforce a unique undefined value, one approach is to generate this value explicitly to test against, such as (void) provided by some implementations. Alternately we could provide a test such as undefined?. Either approach breaks compatibility with existing extensions, and may be prohibitively difficult to implement for compilers lacking a separate undefined value type. Some programmers also consider testing for this value sign of a broken design.

Vote generate for a (void) procedure, test for undefined?, and both for both.

Cowan
I really don't like this; it encourages people to have such a defined-undefined value, which is semantically bogus.
Ganz
But hopefully will be irrelevant based on #68.
Gleckler
Undefined should be undefined. Being able to test for it makes it defined. Implementations should be given freedom to interpret undefined in a way that is appropriate and efficient, not constrained in this strange and contradictory way.
Hsu
Testing for this value is bad practice. Likewise, there is no reason that this procedure must return a single value. Systems like Chez Scheme normalize to this void object, but the point of (void) is to enable one to explicitly make a procedure return unspecified values. This is valid whether or not we have zero, one, or any number of unspecified values returned (#68). It is useful regardless, and I would like to have it regardless of the outcome of #68.
Medernach
Testing undefined values is strange to say the least... It seems better to have error handling instead when appropriate.
Rush
This is fairly important to get right. I used to advocate the "both" position, but Ihave since decided that many of the use cases for (void) and undefined? are much better served by using explicit-CPS forms (particularly is searching applications). Hence my "none" vote is a positive vote that none is the right thing, rather than a "Let's not do anything about this" vote.
Shinn
It's a bug to write programs which rely on this - unspecified is unspecified, and may be anything or even vary per compiler and program and call.
SnellPym
Undefined values are room for future expansion, not specific null placeholders. I've used Chicken's (void) as a substitute for returning no values (and then relied on it being equal to itself in unit tests that force me to check the return value of procedures called only for side effect...); I'd rather put (values) at the end of side-effect-only procedures and have a test macro for this case, that doesn't compare return values!

#51 support for cyclic structures in primitives

list?, length, equal? and other fundamental primitives may diverge when given cyclic data. In the former two cases, avoiding this is simple and not inefficient, and the equivalents are already provided in SRFI-1. In the latter case a proposal was made and rejected on the R6RS list. In the former case, R6RS seems to require list? return #f and length raise an error.

Do we want to specify the behavior when these primitives encounter cyclic data?

Options are equal? to specify equal? must terminate on cyclic input, r6rs to specify R6RS behavior for list? and length, srfi-1 to specify the SRFI-1 semantics (where length returns #f) and equal?+r6rs or equal?+srfi-1 are options for both.

Gleckler
We shouldn't force implementations to be slow in the usual case just to handle the possibility that they might encounter cyclic structures.
Harvey
I think I must be misunderstanding the issue about EQUAL?. You want to specify that it *must not terminate*? That seems, um, draconian.
Medernach
Don't let 'length' returns #f, please raise an error instead.
Rush
anything other than the listed choices is stupid, really.
Shinn
equal? is dangerous to use if it may diverge. It would be reasonable to leave this unspecified, but since we already require shared structures checks for write it seems consistent to make the same requirement for equal?.

#69 Dynamic Parameters

Old-fashioned Lisps used dynamic extent of variables. Although Scheme has switched to lexical scope, the concept of a dynamic environment can be useful in special cases.

Instead of special variables, SRFI-39 provides first-class "parameter" objects with dynamic bindings. Do we want to provide something similar?

Harvey
My instinct is to vote "no" on everything, but I'm swayed by the argument that if we don't do it we'll get some hideous monstrosity foisted on us by wg2. :-)
Shinn
Explicit mutation is the uncommon case, and I think it's safe to leave the semantics of this unspecified in the presence of threads. It's crucial, however, that parameterize be thread-local.

#70 accessing the system time

Short of a full time and date library, a single procedure

(current-seconds)

returning the epoch time in seconds, possibly as a real number, would be useful and is sufficient to implement a full library (though access to the host system's timezone would be desirable in that case).

Since some systems may not have access to a clock, we could make this an optional procedure. Alternately, it could be defined as a simple counter in such cases, providing an accurate notion of time ordering but no sense of duration. Finally, it could return #f in the absense of a clock.

Medernach
We should make a difference between a date (social convention about naming points in time) and a measure of a time interval. IMHO this has to be optional and inside a module. ( And if this is optional we need of course a standard feature identifier to know whether it is present or not. ) About counter option, I would prefer not current-seconds returns tick instead of seconds : If only ticker is available it may be better to have a "current-tick" function instead in order to know that this is not seconds but ticks.
Rush
where's the "module" option? My vote is technically complicated here. This is a great wg1 library function, but the way this is worded (and the voting options) seem to less than obviously allow it as such.
Shinn
This is a *huge* can of worms. POSIX time is simply a bug, and I would rather not have any time API than put it in WG1, but I want time to consider alternatives.

#109 elapsed time

Should we have functions allowing a program to compute elapsed time, as distinct from calendar time?

TimeCowan contains a proposal.

Medernach
This has to be optional feature. A timer (or a ticker) is a definitely distinct from calendar time. I don't get the "jiffy" rationale. Something like the Chronometer proposal is more appealing to me because the reference time point is clearly stated.
Shinn
I don't see the point of this. Time should be handled properly by #70 or not at all.

#78 Should we have case-lambda?

Should we provide case-lambda as in SRFI 16 and R6RS? It provides simple overloading of procedures based on the number of their arguments, and does not require that optional arguments appear only after mandatory ones.

Cowan
Overloading by argument count makes the most sense for a dynamically typed language, and it's just a syntax-rules macro.
Rush
I would like to see a pattern matching facility in Scheme that doesn't suck. Unfortunately, doing that crrectly depends heavily on getting the user aggregates question correct. I suggest that if there is a strong positive response to this question that the aggregates question be held open as well
Shinn
case-lambda is widely implemented but I think encourages bad style. It's a terrible API when you want optional arguments, and is less expressive than a more general match-lambda.

#82 missing port? procedure

It's not clear whether R5RS requires a PORT? procedure or not. It's listed in Section 3.3.2 under Disjointness of Types, but not under section 6.6.1 under Ports. R6RS requires it. Racket, Gauche, MIT Scheme, Gambit, Chicken, Guile, SISC support it; Scheme48/scsh, Kawa, and Chibi currently do not.

Shall we require it?

Cowan
Yes, do it; what the hell.
Rush
please let's not be silly
Shinn
This is trivial to define and often provided.

#107 port status detection

Currently there's no way to determine whether a port is open or closed, short of trying to read/write to it and catching an error. Do we want to add an interface to this?

Cowan
Port-open? is positive, and most of our predicates are in the positive: zero?, for example, not non-zero?.
Gleckler
There should certainly be some way to test whether a port is opened. I prefer to test the positive case, i.e. whether the port is open.
Rush
avoiding exceptions is good.
Shinn
In most programs you should know the lifetime of the port, but in some cases this is necessary. I prefer port-open? because it's more common to want to test the "positive" capability of reading/writing before doing so.

#87 Allow multiple producers in call-with-values

In R5RS and R6RS, call-with-values takes two arguments, both procedures. The first is a producer of multiple values; the second is a consumer, to which the multiple values returned by producer are passed as arguments.

A possible extension is to allow multiple producer arguments, flattening all the produced values together, analogous to Common Lisp's multiple-value-call.

Do we add this extension?

Cowan
My proposal.
Medernach
I don't see the added value of this.
Rush
I mean "NO". really. call-with-values should be *eliminated* from the language.
Shinn
Just because CL has something doesn't mean we should, and I haven't seen any convincing cases where this extension is useful.
SnellPym
This smacks of bloat to me

#88 SRFI 87: => in CASE

SRFI-87 extends case with a => clauses, analogous to the use of => in cond clauses, which allows you to pass the item actually matched to a procedure.

Do we add this extension?

Cowan
Makes a lot of sense to me when you want to make the default do something outside the realm of case, like handle lists or vectors.
Medernach
We trivially have <key> already in lexical scope, don't we ?
Shinn
Syntactic sugar, rarely needed and easy enough to get around with an extra let.
SnellPym
It makes sense to be consistent with cond.

#89 SRFI 61: COND => with generator and guard

SRFI-61 extends => clauses in cond with an optional guard form, such that after the value is generated and found to be true, it's further checked against the guard. If the guard returns #f the clause fails and processing proceeds to the next clause, otherwise the clause is accepted as normal.

Do we add this extension?

Cowan
This one also makes a lot of sense to me.
Gleckler
This unnecessarily complicates COND.
Hsu
This is a good step towards unifying the syntaxes of various dispatch mechanisms, such as syntax-case, match, and cond.
Medernach
Not for WG1, Ok for WG2 if one wants it.
Rush
are we going to have a referendum on every SRFI?
Shinn
cond is complicated enough as it is.
SnellPym
This is kind of nice, but strikes me as a super duper optional extension rather than part of a jewel-like core.

#90 Multiple values in COND => clauses

Currently, => clauses in cond accept a single value from the generator (right-hand side) and pass it to the receiver (left-hand side). Shall we allow the generator to return multiple values and pass them to the receiver? If both this ticket and #89 pass, multiple values would also be allowed for generator/guard cond clauses.

Cowan
I said "Sure, why not?" but Alex convinced me not to, though I don't find all of his rationale convincing.
Gleckler
This doesn't make any sense. First, it's the left-hand side that is the generator and the right-hand side that is the receiver. And if the left-hand side generates multiple values, which one is tested for truth?
Lucier
Aren't "left-hand side" and "right-hand side" reversed in the description?
Rush
multiple-values is bad. the right thing to do is pattern match.
Shinn
Emphatically no. The whole point of => clauses is they are testing that the value generated is true - if multiple values are generated, which do we test for truth? Any semantics will be unintuitive to some. In addition, this will make => clauses slower in most implementations even if MV aren't used, because you need to account for them and box the result in the general case.
SnellPym
Multiple values shouldn't be second-class citizens. It's ugly when you can't use the usual niceties of Scheme just because you've broken out into multiple values.

#91 INCLUDE at the REPL

Should we allow (include "''filename''") at the REPL? This is distinct from import in that it just loads code without altering the module structure.

Cowan
Absolutely yes. This is a way of bringing chameleon code into the current context without having to mess with the module system. Modules are good; required modules are not so good.
Shinn
I don't see the point of this over load. The original ticket refers to load handling binary files whereas include would not, but in the proposed standard load isn't going to handle binary files anyway (beyond implementation-specific extensions).

#92 Case-folding flags

The default reader in R7RS will default to case-sensitive, but users may wish to override this in some situations. R6RS allows at the top-level #!case-fold and #!no-case-fold read syntax to control the case-sensitivity of the current file. Many existing R5RS implementations, on the other hand, use #ci and #cs, with the difference that they refer to the next datum only.

Note PortsCowan provides a separate means of controlling case-sensitivity per-port.

Vote per-datum for the next-datum-only #ci/#cs syntax.

Cowan
Next-datum-only is annoying. However, include-ci would subsume this.
Ganz
if both, per-datum takes precedence.
Rush
this will be a WG1/2 compatibility issue. decide it here whichever way.
Shinn
Per-datum flags can be handled entirely by read without any need for mutable state. I also dislike all #! forms (of which there are currently none).

#116 Source File Character Encoding

The standard currently says nothing about the character encoding system of source files. Do we require this to be a fixed encoding such as UTF-8, use an out-of-band specification like the Emacs (and Python) -*- coding: foo -*- convention, or just leave it unspecified?

Shinn
The emacs approach is handy but too much of a kludge to go into the small Scheme standard, and I don't want to force utf-8.
SnellPym
I say "utf-8", but implicitly I assume that this is also bound by the implementation's restriction no available character set, so as not to require "full Unicode", so ASCII-only is Just Fine. Allowing specification of encoding names, like XML/emacs/Python, then requires standardising what encodings are allowed - and if implementations are allowed to support other encodings as well, then interoperability suffers.

#93 Removing string mutability

R6RS relegated string-set! to a module, and many modern languages tend towards making strings immutable. Removing entirely, however, breaks IEEE Scheme compatibility and should only be considered if you believe mutable strings are fundamentally broken.

Do we remove string-set!? Vote yes to remove, module to relegate to a module as in R6RS, or no to keep as is.

Cowan
See Removing `string-set!` from R7RS small Scheme for my arguments.
Rush
Scheme is a language with mutable bindings and data structures. deal with it.
Shinn
I consider mutable strings a design mistake in Scheme, but we need to preserve backwards compatibility so I prefer to discourage their mutation by putting them in a module. This is not just a symbolic gesture (like putting pair mutators in a module), because there are already existing Scheme implementations for which string-set! is very expensive.
SnellPym
Mutating strings gets us into a while characters-versus-graphemes-versus-codepoints Unicode mess. Plus, immutable strings open the doors for some useful efficiency gains.

#83 Auxiliary Keywords

In R6RS auxiliary keywords (such as else in cond and case forms) are explicitly exported from the (rnrs base (6)) library. Do we want to bind and export these from the core library?

If else is bound in the default module, then it must be imported at the call site whenever using it in cond or it won't match hygienically.

If else is not bound in the default module, then it must not be bound or imported at the call site whenever using it in cond or it won't match hygienically.

Another option is to specify for cond and case that they match the else identifier literally, ignoring any hygiene. This breaks compatibility with R5RS and R6RS.

Cowan
Binding them is more in line with what people expect.
Rush
I'm not sure i understand the ramifications here. I think that the ballot is saying that unbound is the R5rs comaptible way, which we've been living with long enough to at least not be surprised by...
Shinn
else is conceptually unbound in the standard env and so should be specified as such (although for case it actually makes sense to match unhygienically since no other identifier would be legal).
SnellPym
I prefer the unhygienic option since it helps avoid confusing errors due to accidental failure to manage else properly. Likewise, I prefer unbound to bound as it reduces the window for accidental failure.

#101 exactness and eqv?/equal?

In R5RS eqv?/equal? are in some sense the broadest tests for equality, comparing structural equality, but also tests for the same exactness, so that

(equal? 0 0.0) => #f

whereas

(= 0 0.0) => #t

Some users consider this confusing, others sometimes want an equal? that behaves like = for numbers.

Do we want to change equal? and eqv? in this way, or add a separate exactness-agnostic procedure? Vote yes to change, equal=? or inexact-equal? for separate procedures of those names (plus the analogous eqv=? or inexact-eqv?), or no to leave as is. Alternately, write in a separate name.

Cowan
What I really want is to leave equal? alone and add equal=?, which should do what equal? does except for comparing numbers with =.
Hsu
There is no reason to eliminate the extra precision when we have a test = that handles the less precise test. We can easily make eqv=? if we want, so let's not muck up the standard with something like this.
Lucier
Please don't change it. Numerical equality is something different from eqv? and equal? equality. Right now we also have (define x (/ 0. 0.)) (eqv? x x) => #t (at least in many Schemes), yet (= x x) => #f. The needs of numerical = are different from the needs of equal?/eqv?/eq?, and each should be allowed to evolve independently of the other.
Rush
I would just like to note that inexact-equal? should also have an optional tolerance parameter
Shinn
These are a common source of confusion, but I don't like breaking backwards compatibility, and think yet another function may prove even more confusing.

#102 module syntax name

A bikeshed color issue, we need to choose the actual names for the module syntax for the winner of #2.

import, export and include are fairly universal and no alternate is suggested unless someone wants to write in a proposal.

The enclosing syntax can be called either library as in R6RS, module or some other proposal.

Cowan
I keep vacillating between "We should use library for R6RS compatibility" and "Our modules aren't really R6RS-compatible, using library is false advertising." Reluctantly I think familiarity wins.
Hsu
I want module saved for a purely syntactic entity that doesn't exist at all at runtime. Library is already the closer match from R6RS, so let's use that.
SnellPym
Pure stylistic preference. A module is a modular unit of code; a library is (to me) a module meant for sharing between programs. Modules may be used to provide structure within programs, or to make libraries.

#103 module body syntax name

Similar to #102, we need to choose a name for the form to include Scheme code directly in a module form. This can be body as in the proposal, begin or some other name.

Cowan
I prefer begin because it's a begin-block anyway.
Shinn
begin is used in the Scheme48 syntax, but it really doesn't mean the same thing as normal begin, and takes up an important binding in the module description language.
SnellPym
Adding new symbols seems redundant to me.

#105 case-insensitive module includes

The include module form includes files literally with the default case-sensitivity. An include-ci form could include files case-insensitively without resorting to the reader hacks proposed in #92, allowing existing R5RS libraries to be used without modification.

Cowan
The best idea yet for mixing case-folding and case-sensitive code.
Hsu
This can be implemented with a reader parameter and unhygienic macros, but absent those, this makes sense, and it is generally useful.
Shinn
This is easy to implement and is a nice way of providing backwards compatibility without any reader hacks.

#106 conditional code selection

Users invariably want some way to conditionally select code depending on the implementation and/or feature set available. CondExpandCowan allows conditional expansion in the style of SRFI-0 within the module language. SRFI-0 provides cond-expand, SRFI-103 provides a library naming extension, and numerous other personal hacks exist.

Do we want to include something along these lines in WG1 Scheme?

Hsu
None of these are good enough to put in a Small Scheme. Let WG2 have it.
Medernach
Definitely needed, however not so sure if it is the right choice.
Shinn
Something like this is very much needed. The search path extension is a hack, so I choose cond-expand, but I don't think a standard set of features belongs in WG1, even if they are optional.

#108 immutable data interface

R5RS specifies literal data in source code as immutable, but otherwise provides no way to generate or introspect immutable data.

One proposal is given in ImmutableData, providing mutable?, make-immutable and immutable->mutable.

Racket, for which all pairs are immutable in the default language, needs some way to generate shared and cyclic data structures at runtime, and provides the shared syntax for this. It also has an immutable? utility as the complement to mutable? above.

Cowan
Too much too soon.
Gleckler
I agree with John. It's just too early for standardization of ideas like this.
Hsu
I think this needs more discussion and proofs.
Medernach
As stated earlier I personnaly think these are orthogonal features and I like both. Now there was not enough discussions about it to be included.
Shinn
This is a complex topic which hasn't generated much discussion, and is better left to WG2. The ImmutableData proposal in particular is underspecified, and needs some discussion of whether it's a shallow or deep copy, how it handles closed variables, inherently mutable data-structures like ports, etc.

#111 require equal? to return #t if eqv? does

Currently equal? is strictly broader than eqv? except in the pathological case of comparing the same circular list with itself, for which eqv? returns true and equal? may loop infinitely. We could explicitly require equal? to check and return #t in this case, which most implementations do as a performance hack anyway.

Cowan
This was my idea.
Ganz
Only if equal? passes on #54.
Shinn
This is an ugly special case to patch up something that should be handled by #51. If you're passing potentially circular structures to equal? at all in the absense of proper circularity handling you have a bug in your program.

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? The r6rs option is just for the core exception handling.

Cowan
I now think that r6rs is better than cowan, now that I understand R6RS better, so I'm voting against my own proposal here.
Gleckler
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.) However, this ballot item is only for the core exception handling system, not the taxonomy. I wish we would still standardize on some taxonomy rather than none. Without a common exception taxonomy, it's hard to share code.
Hsu
Better to go with R6RS than yet another system. Either that, or let WG2 have it.
Medernach
I feel exceptions as inappropriate for WG1: we already have the flexibility of call-with-current-continuation. Moreover existing exceptions taxonomy are difficult to unify adequatly without making some complex, ad hoc, and unfortunate kludge.
Radul
The only reason I can imagine for wanting exceptions in the core is to specify which conditions various provided procedures (including ERROR) will raise. Leave this to WG2: let them amend the specifications of any WG1 procedures with their behavior in exceptional circumstances.
Shinn
Exception systems have subtle semantics and we should not specify anything that hasn't even been implemented.

#19 when to throw an error

R5RS defines many things as "is an error" without any specification of what happens in that situation. R6RS goes to the opposite extreme and specifies as much as possible what exceptions are raised when.

Taking into account the system provided by ticket #18, we need to come up with guidelines for when exceptions should be raised, and clarify which R5RS "error" situations should raise an exception or be left unspecified.

R5RS specifies only 3 situations where an error is required to be signalled, leaving most situations unspecified as described in ErrorSituations.

Medernach
Discussions needed.
Shinn
I think there's probably a good line between r5rs and r6rs here, but no one has drawn it yet, and it's reasonable to stick with the r5rs default.
SnellPym
I think it's important for portable code to be able to know how to handle various kinds of errors. Most of the errors in ErrorSituations are likely to be programming errors, but even they need to be catchable in systems that host "foreign" code - from sandboxes to "application servers".

WG1 - I/O

#28 binary I/O ports

Do we provide any binary input or output ports, and if so how do we construct them and operate on them? Can binary and textual operations be mixed on the different port types?

PortsCowan provides binary port operations along with other extensions.

R6RS provides an entirely new I/O system, as well as a separate R5RS-compatible I/O system.

The withdrawn SRFI-91 provides yet another I/O system supporting binary ports.

Note this item as well as #29 and #31 specify semi-orthogonal aspects of I/O systems which are typically specified together by individual proposals. If the same proposal doesn't win for all three, the aspects will be merged as needed.

Hsu
I have not had enough time to read over the history of these things, and I need more time.
Shinn
I think it's a mistake to _require_ implementations allow mixing of binary and character data, even if some implementations already do so.

#29 port encodings

Do we support encoding and decoding text from ports with different character encoding systems? Different end-of-line conventions? Different normalizations? How are encoding errors handled?

Cowan
I've modified cowan here to allow rather than require these facilities.
Hsu
I need more time for this one.

#31 custom ports

Do we provide a mechanism for custom ports, on which for instance string ports could be created?

R6RS as well as a number of Scheme implementations provide custom ports with various APIs.

Cowan
Too messy. A custom port is basically a record of procedures, but there's no principled way to decide what the fields should be.
Gleckler
Unless we do a comprehensive survey of how existing implementations handle this idea, we shouldn't try to standardize it.
Hsu
This needs more discussion. I recall hearing some complaints about the R6RS system, but I do think that custom ports are universal enough to warrant consideration.
Medernach
Discussions and review needed
Rush
why is there not a wg2 option?

WG1 - Libraries

#36 hash-tables

R6RS and SRFI-69 both provide hash-table interfaces. Do we provide either of these, or try to provide some primitives on which efficient hash-tables can be implemented?

Cowan
Reluctantly I think we need to push this off on WG2. This sucks, because I think all languages should have a map datatype.
Radul
If we're going to specify hash tables, we must allow room for holding the keys and/or values weakly. There must be system support for this from the garbage collector --- it cannot be written in user code.
Rush
I actually want to say "yes" to primitives, but there doesn't seem to be an option
Shinn
Exposing the eq?-hash function in SRFI-69 is a mistake.
Sussman
Must include weak structures and ephemerons, because these structures cannot be built with user code.

#113 directory contents

We've decided to add file-exists? and delete-file, essential for a large class of scripts, but still have no way to get a list of files in a directory. Do we want to provide an interface to this?

Cowan
I agree with Gleckler that cowan is too complicated, but directory-files is too simple in a world of very lengthy directories, so I go with directory-streams (just open-d-s, read-d-s, and close-d-s).
Gleckler
The directory-files proposal is the only one that is simple but useful. The cowan proposal is too complicated for such a simple purpose, and conflates ports with directory reading unnecessarily. The directory-streams proposal uses the term "stream" for something other than what is conventionally meant in Scheme usage, and it's overcomplicated, too.

WG1 - Macros

#48 let-syntax

let-syntax and letrec-syntax has known ambiguities in their behavior. We have the option of altering the semantics to correct this behavior, defining which behavior we intend, or removing let-syntax entirely. We could also leave this ambiguity unspecified.

The question of whether or not to introduce a new lexical scope (i.e. whether internal defines are visible outside the let-syntax) is straightforward.

If we don't introduce a new lexical scope, the question arises whether or not internal define-syntax forms are allowed and whether they apply to the body of the let-syntax, forms following the let-syntax, or both.

If internal define-syntax applies to the body, we may also wish to specify what happens when said define-syntax redefines an identifier bound by the enclosing let-syntax. This varies by implementation and may be difficult for macro expanders to change, so is left unspecified in the proposals below.

Cowan
R5RS was lexical under the plain meaning of the text, and I think changing that in R6RS was a mistake.
Hsu
I am voting for LetSyntaxArcfide with the understanding that it is proposing a new approach to let-syntax functionality rather than being a fully finished product. I believe that let-syntax is not very useful if it does not splice, and not very correct if it does, so I don`t like having it around.
Rush
I suspect that let-syntax becomes much less necessary in the presence of a module system.

#97 syntax-rules special literals

... and with the result of #6 also _ have special meaning in syntax-rules patterns, so they are not treated as pattern variables by default.

However their behavior when used in the literals list of syntax-rules is ambiguous, and simply breaks in most implementations.

Rather than breaking, it makes sense to go ahead and treat them as normal literals, overriding their special meanings.

In particular, there are many existing R5RS macros which make use of _ in the literals and are thus broken outright by #6. Allowing them as literals fixes these macros.

Cowan
Makes sense to me.
Hsu
Getting these with special meanings makes sense, but if an user puts them in the literals list, then we should not surprise them by breaking. However, if we do break, then an error should be the result, and not some silent failure.
Shinn
This fixes the R5RS macros that the new _ pattern breaks.

WG1 - Modules

#3 module naming convention

We need a naming convention for the core modules and standard libraries of the new module system.

In R5RS everything is effectively in a single module. R6RS provides a much more fine-grained breakdown of modules which could be retro-fitted to the bindings we include in our standard.

John Cowan has proposed a number of module factorings in items #71, #72, #73, #74, #75, #76, #77, as well as an I/O module breakdown in PortsCowan.

Since the naming and breakdown must be internally consistent I'm grouping these into a single ballot item. Members desiring to put forth a new proposal should specify where all bindings belong, or specify a subset of the bindings and default the rest to some other proposal.

Note some ballots specify explicitly whether or not the bindings in question are intended to be in a module or the core language. In these cases we still need to decide to which module they belong. Where specific votes contradict general factoring proposals, the specific vote wins.

SnellPym
I think we need to actually gather a list of what's going in modules, and then make a decision then.

WG1 - Numerics

#79 rational-expt

Often a rational-only exponentiation function is useful; that is, a rational number raised to an integer power. Should we add this procedure to the core so that exponentiation is available even if inexact rationals are not provided or not imported?

Cowan
My idea.
Lucier
I don't see what inexact rationals has to do with expt. Current expt can do the proposed operation without difficulty.
Medernach
I don't get the point, isn't it already the job of expt ?
Shinn
I completely fail to see the point of this - is it motivated by some sort of efficiency concern, or perceived module factoring? Either rationale is misguided - expt is fine for rational as well as all other numbers.

#81 What numeric tower variants should be supported?

NumericTower lists a plausible set of ten from fixnums only to the full monty. Which ones should we allow an implementation to provide? R5RS requires only fixnums large enough to handle string and vector indexes, while R6RS requires the full numeric tower.

Vote on the minimum level of support you want to require (implementations may of course still provide more than this). I've included only the most likely options below, write in other options if needed.

Note quaternions are a fairly rare numeric type, known to be provided only by extensions to scm and chicken, and thus may be difficult for other implementations to support if required.

Cowan
None of these satisfy me at all. I wish this had been given as "Which NumericTower feature switches should be forced to true, forced to false, or undetermined by the standard?"
Medernach
Why do we have to require anything beyond fixnums ? Some embedded systems lacks floating point arithmetics. That issue aside, why not standardize these features as modules ?
Rush
I like the idea of having quaternions around, they are essential for a lot of 3d geometry. However they are definitely a wg2 feature!
Shinn
We have a rich numeric tower, but there's no need to require the whole thing and rule out simple implementations.

#100 integral division

R5RS provides quotient, modulo and remainder for integral division. R6RS extended this with div/mod and div0/mod0. A thorough analysis of possible division operations is provided in DivisionRiastradh, which includes a proposal for five separate division operator pairs. We need to choose which API we'll provide.

Cowan
Riastradh convinces me.
Lucier
I am not a fan of div0/mod0 in r6rs, and I don't recommend it for wg1. I would prefer to keep quotient/remainder from r5rs, and add div/mod from r6rs (where modulus is a synonym for mod). I see these operations as number-theoretic operations, so I would prefer that they apply only to integers.
Rush
what i would really like id DivisionRiastradh with the use of multiple values replaced by using pairs. In spite of the complexity, this proposal has the kind of small-scale getting-it-right quality that is very Schemely
Shinn
The R6RS operations are clearly bad, but I'm unconvinced we need everything provided by DivisionRiastradh.
SnellPym
I am drawn, moth-like, to the awesome rigor of Riastradh's proposal, even though it makes my "not jewel-like" glands itch at the same time.

WG1 - Reader Syntax

#12 symbol literal extensions

In R5RS, symbols parsed as any sequence of valid symbol characters that does not begin with a character that can begin a number. The three exceptions +, - and ... are also provided. This allows parsing with only constant lookahead to determine type.

R6RS added additional exceptions for symbols beginning with ->, a common idiom, still allowing parsers to determine type with a constant lookahead.

John Cowan proposes allowing anything that cannot be parsed as a number to be a valid symbol. This removes the special case exceptions, but may require arbitrary lookahead.

Alex Shinn proposes symbols are any sequence of valid symbol characters that does not have a prefix which is a valid number. This removes the special case exceptions, allows constant lookahead, and allows extensions to number syntax.

Cowan
I've been convinced by Alex's rationale here: we need a little kick room for extending number syntax in the standard later on.
Shinn
It's important to leave room for numeric extensions, such as quaternions and units which are already provided by some Schemes. The cowan proposal makes this impossible. Ease of parsing, both by computers (not requiring arbitrary lookahead) and by humans (being able to tell if something is a number or symbol at a quick glance) is also a concern which should not be dismissed lightly. Both of these issues are addressed by the shinn proposal, which has just as simple a description and removes the special cases of R5RS and R6RS.

#84 Need to decide on a list of named character escapes

The WG has voted to have a list of character names.

The list in R5RS and the longer list in R6RS are only informative. I suggest adopting the R6RS list and making it normative.

Cowan
My idea.
Shinn
The list is somewhat arbitrary, and I'd be open to other suggestions. Mostly I consider it important to make characters used for terminal manipulation avaiable, and to kill the vertical tab. The only character I debated on and ultimately left out was formfeed.

#104 list of mnemonic string escapes

Similar to #84, we need to choose a specific list of mnemonic escapes like \n and \t to be recognized in strings.

Cowan
My idea.
Shinn
These should be consitent with #84.