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

WG1Ballot­Results

alexshinn
2010-10-17 18:20:31
4updating results with finalized ballots and inlined rationaleshistory
source

Notes about results:

WG1 New Ballot Items

WG1 Ballot Items To Finalize By Oct. 12

Working Group 1

#1 Which VCS do we use?

We need a VCS to keep track of changes to the standard as we start drafting it.

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.

Harvey
Honestly, after reading a bazillion emails on this topic, I'm having trouble understanding the differences among these proposals. They all claim not to screw up the REPL, which is the important thing. But if "wg2" were an option it'd definitely be my first choice.
Medernach
This is only a preference indication, more work need to be done in this area before deciding a final module system.
Shinn
I think we should extend this item.

WG1 - Core

#40 SRFI vs. R6RS precedence

Given equal technical merit and compatible extensibility for WG2, should WG1 prefer SRFIs or standardized behaviors from R6RS when faced with the choice. For example, a version of syntax-violation vs. syntax-error.

This is a meta-item, to be used only as a guideline.

Ganz
I'd prefer to decide case-by-case...in this case syntax-error
Harvey
"Given equal technical merit" is so unlikely that I don't think this will ever actually be invoked. But the less like r6rs the better I like it!
Medernach
It is difficult to decide of a general rule. What matters mainly is what people really use and find most useful.

#37 transcript-on and transcript-off

These were relegated to a compatibility library in R6RS. Do we want to keep them, drop them, or move them to a library?

Yes means to keep them in the core, as in R5RS, and no means to remove them entirely.

#38 letrec*

R6RS added letrec* and defined the semantics of internal define to be equivalent. Do we want to add this?

Choose letrec* just to add the syntax, define to change the behavior of internal define, or yes/both for both.

SnellPym
I don't see letrec* as being a large burden to implementors, and having it available to define internal define in terms of tidies up a few loose ends. However, I'm all for putting it in a module as it's a "library" tool that could be implemented on top of the core as a macro.

#41 Should we adopt the SRFI-1 extension to MAP and FOR-EACH?

This extension allows the list arguments to be of unequal length, and stops the procedure whenever any of them run out. R5RS says the lists must be of the same length, R6RS says they should be.

Yes to allow unequal length.

Medernach
Silently accepting lists of unequal length is error-prone, especially if argument lists are received in parameters and if we are not sure about their length, it means we need to check at every map / for-each call if lists are on the same length, really not a good idea to my opinion. If one wants a mapping function accepting unequal length lists it is easy to write its own version.
SnellPym
Shouldn't be a large burden, and removes a 'hole' in the semantics of map/for-each.

#42 Should we adopt the SRFI-1 extension to ASSOC and MEMBER?

This extension accepts a third argument, the equality predicate to be used. Alternatively we could use the R6RS predicates ASSP and MEMP.

SnellPym
The SRFI-1 form just strikes me as neater.

#33 dynamic-wind

New to R5RS, do we reaffirm the sometimes debated dynamic-wind?

Removing this would require a strong rationale indicating that it's fundamentally flawed.

SnellPym
It's essential for maintaining certain kinds of invariants in the presence of continuation trickery, even though people misunderstand it sometimes.

#34 multiple values

New to R5RS, do we reaffirm multiple values, specifically the procedures call-with-values and values?

Removing this would require a strong rationale indicating that it's fundamentally flawed.

Note if these forms are removed or placed in a module, for consistency none of the core library should return multiple values (as is the case in R5RS).

Yes to keep them, no to remove them, and module to relegate them to a module.

Shinn
I really hate MV, but would rather preserve backwards compatibility by relegating it to a module.
Sussman
It is important to allow multiple values that can result in multiple definitions and assignments, but it is not apparent to me why we need a special data type to implement them.

#54 optional arguments

Scheme's primitive mechanism of improper lambda-lists allows for optional arguments, but only with extra machinery. CL, DSSSL, and some Schemes provide a special word such as #!optional in lambda-lists, showing that the arguments which follow are optional and may have default values. SRFI-89 provides both optional and keyword arguments via lambda* and define* and without introducing #!foo special tokens.

Note the original ticket description mentions case-lambda, but this is easily provided as a separate module, and will be a separate item.

Ganz
NAMES ARE PRECIOUS: OVERLOAD lambda AND define RATHER THAN RENAMING THEM
Harvey
Much as I'd like optional arguments, I can't support srfi-89 because it depends on srfi-88, keywords, which are an incompatible change that will break r5rs programs.
Shinn
Too much to work out, too many differing opinions, let's leave this to wg2.
Sussman
WG2 should consider extending the DEFINE and LET syntax to include a nice pattern destructuring language. But don't accept some partially cooked kludge.

#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?

Shinn
This is actually pretty crucial for simple games, but I'd still rather leave it up to wg2.
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.

#59 current-error-port

Pretty much all Schemes except embedded ones provide a notion of current error distinct from current output. Should this be exposed as a Scheme output port?

SnellPym
I vote for 'module' since it's not something that EVERY implementation will have, but many will.

#60 Simple file operations

Should WG1 provide a module equivalent to the (rnrs files) module? This provides delete-file and file-exists?, which are pretty much necessities for any file-driven programming.

Note PortsCowan automatically includes these - voting for them here guarantees them even if not included by a specific proposal.

#64 Consistency in sequence procedures

Should we add the 10 procedures mentioned at CompleteSequenceCowan in order to make the Scheme sequence types consistent? They are `make-list copy-list list-set! string-map string-for-each string->vector copy-vector vector-map vector-for-each vector->string`, all with the obvious interface and semantics.

Harvey
The whole reason we /have/ more than one sequence type is that each is better at some things than others. I don't think we should make it harder to learn which is which!
Shinn
These should be in a module. Arguably, the list equivalents like map and for-each should be in modules too. Their extremely useful but a loop syntax is generally faster and easier to read.
SnellPym
Consistent sequence types give me a warm feeling of symmetry.
Sussman
It is not very good to think of strings as 1-dimensional arrays of characters. What about accents and other hairy stuff? Be afraid! Consider the complexity of Unicode!

#65 Precision indicators

R5RS requires that Scheme support five indicators for the precision of floating-point values, not only the default e but also s, f, d, and l. Only a few Schemes actually support more than one precision, so this is mostly noise. Shall we make it an optional feature?

#66 Add EXACT-INTEGER?

Should we add an EXACT-INTEGER? predicate? Currently, to determine whether a number is both an integer and exact, we must test for both, which requires some hackery or poor pattern matching to optimize in existing Scheme implementations.

Sussman
Compiler shoould be able to optimize "(and (integer? x) (exact? x))"

#44 Testing function arity

We would like a standard for checking function arity. SRFI-102 proposes a way to check function arity:

Ganz
THIS WOULD NEED TO BE EXTENDED SOMEHOW FOR KEYWORD ARGUMENTS A LA SRFI-89
Harvey
Much as I'd like arity information, this is too complicated for wg1, because of its support for case-lambda.

#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 not 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.

Harvey
I think I must be misunderstanding the issue about EQUAL?. You want to specify that it *must not terminate*? That seems, um, draconian.
Hsu
Note: I want R6RS behavior, which requires that all of list?, equal?, and length terminate and return reasonable values. I especially do not like the idea of requiring equal? to not terminate.
Medernach
About shared structures I would prefer an alternative parenthesis syntax for declaring this kind of values something like this: (make-shared ((a 'foo) (b (1 (a b) c)) (c #(2 b))) (list a b c)) equivalent to in SRFI-38 external representation: ('foo #1=(1 ('foo #1#) #2#) #2=#(2 #1#)) The rationale behind it is to avoid wild mutations when building shared structures, and a more human readable notation. Maybe this has to be discussed in a module for graph-like or circular data ?
Shinn
Definitely or list? and length, equal? might need more consideration.

#58 exact-integer-sqrt

Should WG1 include exact-integer-sqrt from R6RS? It allows square root operations in Schemes that don't provide inexact arithmetic, and has different semantics from sqrt, as it rounds its argument down to the nearest exact square.

(exact-integer-sqrt k) => (values s r) ; k = s^2 + r

r6rs/yes for R6RS semantics, list to use a list instead of MV, or single to only return s.

#61 finite? nan?

Shall we add these numeric predicates defined on the IEEE floating point values from #20?

#63 call/cc short name

Should we allow call/cc as an equivalent to call-with-current-continuation?

Shinn
Emphatically no. Aliases do not belong in a small standard.

#53 Implicit BEGIN to implicit LET-NIL

In general, in places where an implict BEGIN occurs, it is possible to change this to an implicit LET-NIL and remain backwards compatible. Should we do this?

This is a meta-item to be used as a guideline, and specific places would need to be brought up for review.

Shinn
I'd only consider this on a case-by-case scenario.

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?

Hsu
I propose that we provide exception handling as specified in R6RS without the condition system, or that we consider the condition system separately.
Shinn
Probably just the core R6RS exception is good here.

#17 error

Do we support the near ubiquitous SRFI-23 error procedure, and if so should it use the SRFI-23 signature, R6RS, or type-dispatch on the first argument to allow both?

Note ExceptionHandlingCowan currently includes a SRFI-23 compatible error procedure.

Hsu
Note: I have a problem with type dispatching on both because R6RS allows for any type of value to be the first argument to the error procedure, which can be convenient, especially with regards to strings.
Shinn
Definitely not the R6RS version, it breaks too much code.

WG1 - I/O

#30 string ports

Do we support string ports, as implemented by SRFI-6 or as by R6RS?

Note that currently PortsCowan provides SRFI-6 string ports.

Hsu
I like the R6RS version better because it separates the port type returned from get-string-output-port and the means of extracting the data. I think this separation is good for a number of reasons, the two primary ones being that we can make it possible for an application to write to an output port without being able to extract the data from the port, easily. Secondly, that the port returned can, if desired, be identical in behavior to a normal textual output port, as opposed to forcing a different port type.
SnellPym
Implementations can provide SRFI-6 through the usual mechanisms, rather than it being put into WG1

#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.

Ganz
SUPPORT AS AN OPTION
SnellPym
Much as it pains me to require more complexity from WG1 implementations, I feel that there is a security issue here that primitives should not diverge on cyclic structures, as it would make it all too easy to introduce unexpected denial of service opportunities.
Sussman
The srfi-38 stuff is certainly valuable, but it really is not essential in the core of the language. This is really a common-subexpression elimination of data objects.

WG1 - Macros

#7 (... ...) ellipse escaping in syntax patterns

A popular extension, formalized in the R6RS, is to allow "(... <templ>)" in a syntax-rules template to be an escape for "<templ>". Do we use this, and if so what does (... <t1> <t2>) mean?

#39 syntax-error

Should we have syntax-error parallel to SRFI-23 error? This is evoked when macros are expanded.

Ganz
OR PARALLEL TO R6RS ERROR?
Hsu
This is not something that we should include natively because the normal way to implement this is through a procedure, which does not work with non-procedural macro systems, which are the only types of macro systems on the table for WG1. We could implement it syntactically, but I think it is better to do this procedurally in WG2.
SnellPym
I think it's good to distinguish a syntax error from a coding error in the macro itself, which should call error.

#5 syntax-rules

Do we keep syntax-rules in the core, relegate it to a standard module, or leave it out entirely (possibly letting WG2 specify it).

Yes to keep in core, no to remove from Scheme entirely.

#10 identifier syntax

R6RS introduced identifier syntax as a way to expand identifiers in non-macro positions.

Orthogonal to the overall macro system and what types of expanders are provided, do we provide a means to specify identifier syntax?

Shinn
Identifier syntax is actually really cool. I bash it only because it's a big semantic change, and not suitable for a small R5RS-compatible language. I would not be overly opposed to it in wg2.

#47 internal define-syntax

R6RS extends define-syntax to be allowed in local lexical contexts. Do we allow this as well?

#6 syntax-rules _ patterns

R6RS adds _ as a wild-card pattern, breaking some existing R5RS macros. Do we add the _ wildcard, or leave it as a normal identifier as in R5RS?

Yes to add, no for R5RS.

#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?

Hsu
This is no longer necessary with the introduction of a proper module system. It is better to do this through the module system than to complicate the syntax of syntax-rules.
Sussman
You mean "ellipsis" not "elllipse"! An ellipse is a shape, an ellipsis is a punctuation mark.

#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?

Shinn
The dotted-tail is useful, but breaks the rule of the pattern language where what you see is what you get.

WG1 - Numerics

#20 inexact infinities

R6RS provides support for inexact infinities and NaN objects. Do we keep these, and if so do we use the same literal syntax and arithmetic as in R6RS?

Yes to keep them with the same syntax and semantics of R6RS, or write in a separate proposal for some other syntax/semantics.

#21 limited type arithmetic

R6RS provides libraries for limited type arithmetic on fixnums only and flonums only (i.e. fx+, fl* etc.). Do we want these?

#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?

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.

Harvey
YES!!!!!!!!!!
Sussman
This is a default only. The reader syntax should be allowed to be specified as metadata on the source of the input. For example, the PLT reader must be specified at the head of a file. However, for compatability and convenience the traditional default for LISP-based systems should be fold-case.

#15 #\foo character names

R6RS greatly extends the list of character names, as well as allowing #\xNN numeric escapes for characters. Do we allow any or all of these names?

mnemonic for #\tab and friends, numeric for #\xNN as in R6RS, and yes/both for both.

The exact list of added names is to be decided later.

Ganz
UNICODE IMPLICATIONS?
Shinn
Conservative in the names - we don't need to specify all control characters from 0..31.

#13 [brackets] as (parens)

R6RS allows [] brackets as identical to parenthesis, with the condition that they must balance. Do we accept this extension, propose some other use for brackets, or leave them unspecified?

Yes for R6RS, no for R5RS, or write in a proposal for some other meaning for brackets.

Shinn
Over my dead body!
Sussman
Actually, I would like [] to be reader syntax for vector data and allow the lambda, cond, let to accept that kind of data as legitimate syntax for lists. Indeed, {} should be allowed to represent sets.

#14 alternate comment syntax

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

Shinn
I don't like or use the block comments, but I suspect I'll get out-voted on this.

#16 symbol escapes

R6RS provides character escapes in symbols of the form \xnnnn;, where nnnn is 1-5 hex digits. Do we accept this extension? Do we also allow |...| to escape a whole symbol or a part of one?

In all existing standards pipes are reserved and the |...| syntax is unspecified. In most implementations it's recognized, but there are at least a few implementations where pipes are normal character constituents.

SnellPym
I think that since string->symbol takes any string, any symbol should be representable in sexprs.

#67 string escapes

R6RS provides character escapes in strings of the form \xnnnn;, where nnnn is 1-5 hex digits, as well as \n, \t etc. C-like escapes for common control characters. Do we accept either or both of these extensions?

SnellPym
The numeric escapes are very useful (for writing non-ascii literals in ascii sources, for a start); the mnemonics are cheap to implement and are useful.

WG1 - Strings and Chars

#24 char and string folding

R6RS provided operations to alter the case of strings and characters (upcase, downcase, titlecase and foldcase) using locale-independent Unicode mappings. Do we provide equivalent mappings?

Note in a Unicode implementation individual character casings are incomplete, and string case is not defined as a simple mapping of case over the constituent characters.

Note UnicodeCowan currently provides mappings at both levels.

SnellPym
Keep explicit dependencies on supporting the entire Unicode stack out of WG1, IMHO

#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.

Shinn
Totally inappropriate for wg1.
SnellPym
Keep explicit dependencies on supporting the entire Unicode stack out of WG1, IMHO

#27 string-ref/set! access time

R6RS suggests string-ref and string-set! work in O(1) time, implying strings are implemented as character arrays. Do we reaffirm this?

Yes for required constant time.

Harvey
Yes unless this somehow prevents Unicode strings, I guess.

#23 character set

R5RS said almost nothing about character sets. R6RS specified full Unicode. Do we specify a character set, or limit the options in any way?

Ganz
I SUGGEST CONSIDERING RUBY'S CSI MODEL AS PER #26 ABOVE
Harvey
Thank you John for brilliantly finding a way to make everyone happy (where "everyone" = ASCII, Unicode, case-folders).
Shinn
Modulo string-normalization, and perhaps some details to be worked out later since it's a large proposal.
SnellPym
John Cowan knows his Unicode.

----

WG1 Controversial Ballot Items

WG1 - Core

#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?

Harvey
But I'd really like a better name than "blob"!
Hsu
I am in favor of John Cowan's small WG1 proposal provided that we change the term "blob" to "bytevector".
Lucier
I'd like "full cowan", what he'd prefer for WG2
Shinn
I think the proposals need more work.

#69 Parameters

Most Scheme implementations provide some form of dynamic bindings such as those provided by SRFI-39 parameters.

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. :-)
Hsu
I find very little of use for a parameter that is not mutable, so I can't see a lot of benefit to Cowan's proposal, of immutable parameters, even if we provides some way to mutate them through parameterize. I disagree with the ParametersSnellPym proposal because it suggests to different behaviors for parameters based on whether they are mutated by themselves or with parameterize. I believe that we should have mutable parameters, and that there should not be a difference whether they are mutated by parameterize or not. I think that we should specify that parameters are thread parameters by default in the case of threads, but I am more than happy to have them mutable and have their thread behavior undefined. Programs written in WG1 will continue to run in WG2 in either case. The main issue is whether a parameter based library imported into a WG2 threaded environment will be able to know what is happening. I'd prefer to avoid it being able to tell, which means that I would like to have the threads have their own state. I am assuming of course that a form of global parameters will be made available. I should develop a proposal on this.
Medernach
I completely agree that some other mechanism is better in order to share data between threads and separating concern is needed here.
Shinn
I think we should have SRFI-9, with parameterize required to be thread-safe and direct mutation unspecified in the context of threads.
SnellPym
Unusually, I prefer the Cowan proposal over my own, as I actually like immutability. However, many people don't, and my proposal is to ensure that (given the concession of mutability), the interaction between threads is handled in a way that lets developers make useful assumptions.

#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?

Shinn
SRFI-9 doesn't extend well, as shown by SRFI-99's ugliness. A fully keyword-based approach may be better.

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?

Ganz
I'D SUGGEST CONSIDERING BALANCED TREES (AS WITH C++ STL), WHICH DO NOT REQUIRE A HASH FUNCTION.
Shinn
SRFI-69 is broken.
SnellPym
I like providing primitives, but wouldn't want to force hash tables to be available to the user in WG1 implementations; they can ask for SRFI-69 if they want it.
Sussman
Must include weak structures and ephemerons, because these structures cannot be built with user code.