- You may list as many of the options as you want in order of preference.
- Options are comma-delimited (ignoring space) and case-insensitive.
- You can pipe-delimit (|) options you want to give equal weight to.
- You may write in your own option if you announce it to the list first.
- You may specify a variant with
option/variant
, for examplesrfi-1/module
to vote forsrfi-1
but clarify it should be in a separate module. Please also include thesrfi-1
option in this case. - You can write a free-form rationale after the "preferences" line,
module
means "yes, but I want it in a separate module",wg2
means "no, but I think it should go in WG2".undecided
means I want to discuss this issue further.- Abstain on any item by leaving the preferences blank.
We need a VCS to keep track of changes to the standard as we start drafting it.
- Options: bzr, darcs, git, hg, monotone, svn, undecided
- Preferences: monotone,hg,bzr,git,svn,darcs
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.
- Proposals:
- ganz: ModulesGanz
- hsu: ModulesAndPackagesArcfide
- shinn: ModulesShinn
- Options: ganz, hsu, shinn, r6rs, r6rs--, undecided
- Default: r6rs
- Preferences: shinn, r6rs--, hsu, r6rs
I've changed my top preference to ModulesShinn for two primary
reasons: 1) It is a compatible subset of R6RS, with two syntactic
differences that should be easy to implement, so it should be easy to
use R6RS libraries that only make use of its subset of the R6RS module
system; and 2) it includes the include
form, allowing code to be
separated from its library specification, which makes it easy to use
code that is intended to be loaded at top level, e.g. in R5RS
implementations, eliminates unnecessary indentation, and feels more
compatible with interactive development.
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.
- Options: srfi,r6rs,undecided
- Preferences: r6rs
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.
- Options: yes, no, module, wg2, undecided
- Default: yes
- Preferences: module,no,wg2
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.
- Options: both, letrec*, define, no, module, wg2, undecided
- Default: no
- Preferences: undecided
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.
- Options: yes, no, wg2, undecided
- Default: no
- Preferences: no
This extension accepts a third argument, the equality predicate to be used. Alternatively we could use the R6RS predicates ASSP and MEMP.
- Options: srfi-1, r6rs, no, wg2, undecided
- Default: no
- Preferences: srfi-1,r6rs
New to R5RS, do we reaffirm the sometimes debated dynamic-wind?
Removing this would require a strong rationale indicating that it's fundamentally flawed.
- Options: yes, no, module, wg2, undecided
- Default: yes
- Preferences: yes,module,wg2
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.
- Options: yes, no, module, wg2, undecided
- Default: yes
- Preferences: yes,module,wg2
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.
- Options: dsssl, srfi-89, no, wg2, undecided
- Default: no
- Preferences: dsssl,wg2
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?
- Proposals:
- cowan: RandomCowan
- Options: cowan, srfi-27, no, wg2, undecided
- Default: no
- Preferences: wg2, srfi-27/module, srfi-27/core, no, cowan/module
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.
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?
- Options: yes, no, module, wg2, undecided
- Default: no
- Preferences: module,yes,wg2
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.
- Options: yes, no, module, wg2, undecided
- Default: no
- Preferences: module,yes
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.
- Options: yes, no, module, wg2, undecided
- Default: no
- Preferences: yes,module,wg2
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?
- Options: required, optional, no, wg2, undecided
- Default: required
- Preferences: optional,wg2
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.
- Options: yes, no, module, wg2, undecided
- Default: no
- Preferences: yes
We would like a standard for checking function arity. SRFI-102 proposes a way to check function arity:
- Options: srfi-102, no, wg2, undecided
- Default: no
- Preferences: srfi-102,wg2,no
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.
- Options: equal?, r6rs, srfi-1, equal?+r6rs, equal?+srfi-1, no, wg2, undecided
- Default: no
- Preferences: no,wg2
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
.
- Options: r6rs, list, single, no, wg2, undecided
- Default: no
- Preferences: yes,module,wg2
Shall we add these numeric predicates defined on the IEEE floating point values from #20?
- Options: yes, no, module, wg2, undecided
- Default: no
- Preferences: undecided
Should we allow call/cc
as an equivalent to
call-with-current-continuation
?
- Options: yes, no, module, wg2, undecided
- Default: yes
- Preferences: no,module,wg2
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.
- Options: yes, no, module, wg2, undecided
- Default: no
- Preferences: yes
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, not the conditions hierarchy.
- Proposals:
- cowan: ExceptionHandlingCowan
- Options: cowan, r6rs, wg2, none, undecided
- Default: none
- Preferences: r6rs/module, r6rs/core, wg2, cowan/module, cowan/core
While the R6RS exception system is not perfect, I'm happy with it. In WG1, it belongs in a module, not in the core.
If we don't agree to use the R6RS system, then I'd rather see WG2 refine it instead of including ExceptionHandlingCowan in WG1, since the ExceptionHandlingCowan proposal doesn't explain the rationale for its deviations from R6RS. I've studied the mailing list archive and can't find a convincing argument for ExceptionHandlingCowan, either, so I'm sticking with R6RS or, as a fallback position, WG2.
The largest flaw I see with the R6RS condition system is that its condition taxonomy is too coarse and focused on operating-system issues. Compare it with the taxonomy of Gambit or MIT Scheme, for example. (See ExceptionTaxonomies for details of the condition taxonomies of many Scheme implementations.)
Some people have proposed taking the R6RS exception system but not its condition taxonomy. If we do, I hope we'll still standardize on some taxonomy rather than none. Without a common taxonomy, it's hard to share code.
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.
- Options: srfi-23, r6rs, both, no, module, wg2, undecided
- Default: no
- Preferences: r6rs,srfi-23,module,wg2
Do we support string ports, as implemented by SRFI-6 or as by R6RS?
Note that currently PortsCowan provides SRFI-6 string ports.
- Options: srfi-6, r6rs, no, module, wg2, undecided
- Default: no
- Preferences: srfi-6,r6rs,module,wg2
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.
- Options: srfi-38, native, no, wg2, undecided
- Default: no
- Preferences: srfi-38/module, srfi-38/core, wg2, no, native
SRFI 38 supports this notation, but doesn't require that read
and
write
support it, so writing doesn't have to become more expensive.
Since many programs won't need this feature, it belongs in a module.
A popular extension, formalized in the R6RS, is to allow "(... )" in a syntax-rules template to be an escape for "". Do we use this, and if so what does (... ) mean?
- Options: yes, no, wg2, undecided
- Default: no
- Preferences: yes
Should we have syntax-error parallel to SRFI-23 error? This is evoked when macros are expanded.
- Options: yes, no, module, wg2, undecided
- Default: no
- Preferences: yes
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.
- Options: yes, no, module, wg2, undecided
- Default: yes
- Preferences: yes,module,wg2
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?
- Options: yes, no, module, wg2, undecided
- Default: no
- Preferences: no
R6RS extends define-syntax to be allowed in local lexical contexts. Do we allow this as well?
- Options: yes, no, wg2, undecided
- Default: no
- Preferences: yes
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.
- Options: yes, no, wg2, undecided
- Default: no
- Preferences: no
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?
- Options: yes, no, wg2, undecided
- Default: no
- Preferences: no, wg2, yes/module
SRFI-46 and R6RS both allow a fixed number of tail patterns following an ellipsis in a syntax-rules pattern:
(P1 ... Pk Pe Pm+1 ... Pn)
R6RS further allows dotted tail patterns
(P1 ... Pk Pe Pm+1 ... Pn . Px)
where Px only matches a dotted list.
Do we allow either or both of these extensions?
- Options: tail, dotted-tail, both, no, wg2, undecided
- Default: no
- Preferences: both, tail, wg2
I don't feel strongly about this issue, but the extensions seem harmless.
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.
- Options: yes, no, wg2, undecided
- Default: no
- Preferences: yes
R6RS provides libraries for limited type arithmetic on fixnums only
and flonums only (i.e. fx+
, fl*
etc.). Do we want these?
- Options: yes, no, module, wg2, undecided
- Default: no
- Preferences: module,wg2,yes
R6RS introduced the concept of mantissa widths as an alternative to the R5RS #s in numbers. Do we want either or both of these?
- Options: r5rs, r6rs, both, no, wg2, undecided
- Default: no
- Preferences: both, wg2, r6rs, r5rs
I don't have a good enough understanding of the importance of this issue to have a strong opinion, so I'm following GJS, who is of course a great mathematician and programmer, and have chosen "both" as my first preference.
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.
- Options: yes, no, unspecified, undecided
- Default: yes
- Preferences: yes, implementation-determined
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.
- Options: mnemonic, numeric, both, no, wg2, undecided
- Default: no
- Preferences: both,numeric,wg2
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.
- Options: yes, no, module, wg2, undecided
- Default: no
- Preferences: no
R6RS provides support for #; nested sexp comments, and #| ... |# nested block comments. Do we include either or both of these?
- Options: sexp, block, both, no, wg2, undecided
- Default: no
- Preferences: both, block, wg2, sexp, no
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.
- Options: numeric, quoted, both, no, wg2, undecided
- Default: no
- Preferences: quoted,both,no
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?
- Options: numeric, mnemonic, both, no, wg2, undecided
- Default: no
- Preferences: numeric,no
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.
- Options: strings, chars, both, no, module, wg2, undecided
- Default: no
- Preferences: module,wg2,both
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.
- agnostic -
string-ni=?' etc. provides an API of basic normalization insensitive procedures without explicitly converting the strings, analagous to
string-ci=?' - generic -
string-normalize
converts to a single implementation-defined normal form - separate -
string-compose-canonical
,string-decompose-canonical
andstring-decompose-compatibility
gives orthogonal control over the normalization being performed - specific -
string-normalize-{nfd,nfc,nfkd,nfkc}
converts explicitly to the four normal forms defined in the Unicode standard
Note UnicodeCowan currently provides specific normalization procedures.
- Options: generic, separate, specific, agnostic, no, wg2, undecided
- Default: no
- Preferences: wg2, specific/module
The complexity of Unicode should be, as much as possible, banished from WG1. If it is included, however, I'll follow John's lead, since he is a Unicode expert, and vote for specific/module.=== #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.
- Options: yes, no, wg2, undecided
- Default: no
- Preferences: undecided
R5RS said almost nothing about character sets. R6RS specified full Unicode. Do we specify a character set, or limit the options in any way?
- Proposals:
- cowan: UnicodeCowan
- Options: cowan, r5rs, wg2, undecided
- Default: r5rs
- Preferences: cowan,wg2,r5rs
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?
- Proposals:
- cowan: BlobAPI
- snellpym: BlobsAndSRFI4SnellPym
- Options: cowan, snellpym, wg2, none, undecided
- Default: none
- Preferences: cowan
Most Scheme implementations provide some form of dynamic bindings such as those provided by SRFI-39 parameters.
- Proposals:
- cowan: ImmutableParametersCowan
- snellpym: ParametersSnellPym
- Options: cowan, snellpym, srfi-39, wg2, none, undecided
- Default: none
- Preferences: cowan, srfi-39, wg2
Do we support any means of creating disjoint user-defined types, such as in SRFI-9, SRFI-99 or the R6RS record system?
- Proposals:
- hsu: RecordsArcfide
- rush: UserAggregatesRush
- snellpym: UniqueTypesSnellPym
- Options: hsu, rush, snellpym, srfi-9, srfi-99, no, wg2, undecided
- Default: no
- Preferences: srfi-99,srfi-9,hsu,snellpym
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?
- Options: srfi-69, r6rs, no, wg2, undecided
- Default: no
- Preferences: wg2,r6rs,srfi-69