Notes about results:
We need a VCS to keep track of changes to the standard as we start drafting it.
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.
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.
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.
When in doubt, dike it out.
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.
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.
This extension accepts a third argument, the equality predicate to be used. Alternatively we could use the R6RS predicates ASSP and MEMP.
Either or both.
New to R5RS, do we reaffirm the sometimes debated dynamic-wind?
Removing this would require a strong rationale indicating that it's fundamentally flawed.
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.
Multiple return values are important, but is seems wrong to do them by introducing a special data type (the frob produced by VALUES) and special implicit destructuring (the lambda list of the receiver argument of CALL-WITH-VALUES) for that purpose alone. Linguistically, it would be much cleaner to just have destructuring in bindings in general, and have VALUES just be a convention for using LIST (or VECTOR).
The circumstances where explicit destructuring of returned compounds is difficult are defining (or assigning) multiple names to be the components of the return of a single expression.
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.
This is feature creep. Optional arguments are a subset of the functionality of a good pattern-matching and destructuring mechanism for bindings. I believe that WG2 should consider such a mechanism.
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?
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.
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?
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.
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.
Except for the string ones. A string is really not a vector of characters --- unicode causes infinite amounts of trouble. But the list and vector manipulations are fine.
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?
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.
Leave the hackery and the pattern matching in the implementation, don't put it into the standard.
We would like a standard for checking function arity. SRFI-102 proposes a way to check function arity:
This is feature creep. It is useful, but since it is not closed, it opens the door to an endless pile of additional features that people will want to solve further and further problems. For example, the procedure returned by calling (lambda (f) (lambda args (apply f args))) wants to have the same arity as F. This must then either be deduced (impossible in general) or specified by the programmer (piling feature upon feature). And it doesn't end there. "No reflection" is a reflection sweet spot; we can jump to the next one if we want, and if we know what it is, but we should not wander aimlessly through this space.
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.
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.
Shall we add these numeric predicates defined on the IEEE floating point values from #20?
Should we allow call/cc as an equivalent to call-with-current-continuation?
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.
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 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.
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.
Do we support string ports, as implemented by SRFI-6 or as by R6RS?
Note that currently PortsCowan provides SRFI-6 string ports.
Perhaps all the I/O stuff can be hidden off in a module? Maybe except a tiny facade of the most basic things?
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.
Some variation on this theme (I would like to see the names for common subexpressions be able to be semantic, and perhaps introduced by an object named something like LET instead of inline) would certainly be good to have around, but it would probably complicate the WG1 language too much.
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?
Should we have syntax-error parallel to SRFI-23 error? This is evoked when macros are expanded.
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.
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?
If a thing wants to change how a form is interpreted, the thing should be in the operator position of that form.
R6RS extends define-syntax to be allowed in local lexical contexts. Do we allow this as well?
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.
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?
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?
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.
R6RS provides libraries for limited type arithmetic on fixnums only and flonums only (i.e. fx+, fl* etc.). Do we want these?
R6RS introduced the concept of mantissa widths as an alternative to the R5RS #s in numbers. Do we want either or both of these?
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.
Really, the read syntax should be settable by appropriate metadata on the source of the input, and case folding should be just one of many interesting options (e.g. the @-syntax in Racket).
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.
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.
It would be better to make brackets be reader syntax for some data structure that is distinguishable from lists, and then, if desired, let LAMBDA and friends allow that data structure to be used as a formal parameter "list". See, e.g., Clojure.
R6RS provides support for #; nested sexp comments, and #| ... |# nested block comments. Do we include either or both of these?
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.
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?
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.
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.
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.
R5RS said almost nothing about character sets. R6RS specified full Unicode. Do we specify a character set, or limit the options in any way?
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?
Most Scheme implementations provide some form of dynamic bindings such as those provided by SRFI-39 parameters.
Do we support any means of creating disjoint user-defined types, such as in SRFI-9, SRFI-99 or the R6RS record system?
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?
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.