Notes about voting:
These were relegated to a compatibility library in R6RS. Do we want to keep them, drop them, or move them to a library?
R6RS added letrec* and defined the semantics of internal define to be equivalent. Do we want to add this?
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.
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.
Shouldn't be a large burden, and removes a 'hole' in the semantics of map/for-each.
This extension accepts a third argument, the equality predicate to be used. Alternatively we could use the R6RS predicates ASSP and MEMP.
The SRFI-1 form just strikes me as neater.
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.
I think the SRFI process makes me happier than the R6RS process did.
Do we support any means of creating disjoint user-defined types, such as in SRFI-9, SRFI-99 or the R6RS record system?
New to R5RS, do we reaffirm the sometimes debated dynamic-wind?
It's essential for maintaing certain kinds of invariants in the presence of continuation trickery, even though people misunderstand it sometimes.
New to R5RS, do we reaffirm multiple values, specifically the procedures call-with-values and values?
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.
Do we want to specify the behavior when these primitives encounter cyclic data?
If not, it becomes all to easy to inadvertently apply one of these primitives to data from untrusted sources, introducing denial of service attacks.
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.
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?
srfi-27 can be asked for by name if it's wanted.
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.
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?
I vote for 'module' since it's not something that EVERY implementation will have, but many will.
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.
Shall we add these numeric predicates?
Should we allow call/cc as an equivalent to call-with-current-continuation?
People can trivially define it if they want it.
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.
Consistent sequence types give me a warm feeling of symmetry.
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.
We would like a standard for checking function arity. SRFI-102 proposes a way to check function arity:
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?
Do we support the near ubiquitous SRFI-23 error procedure?
Do we support SRFI-6 string ports, reaffirmed by R6RS?
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?
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.
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?
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.
R6RS adds _ as a wild-card pattern, breaking some existing R5RS macros. Do we keep the _?
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?
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?
Should we have syntax-error parallel to SRFI-23 error? This is evoked when macros are expanded.
There is a definition in JRM's Syntax-Rules Primer using syntax-rules, but it relies on the syntax-rules implementation reporting an unmatchable pattern with a complaint that includes the pattern.
Decent error reporting isn't hard to implement, and makes macro debugging much easier.
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?
R6RS extends define-syntax to be allowed in local lexical contexts. Do we allow this as well?
For consistency with define.
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?
I've encountered many quantities that seem approximately infinite in my daily life, and being able to model these in software would be useful.
R6RS provides libraries for limited type arithmetic on fixnums only and flonums only. 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.
Case folding is hard to implement in the presence of Unicode, and having had a long history of C programming, I instinctively preserve case myself. People should be discouraged from defining symbols that differ only in case, but only by warnings that it may confuse other readers.
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?
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?
I think there's other things we could do with [], but experimentation is needed before proposing anything.
R6RS provides support for #; nested sexp comments, and #| ... |# nested block comments. Do we include either or both of these?
They're simple parser extensions, and both very useful, and quite widely implemented anyway.
[This ticket was originally about string escapes, but commenters have been talking about symbol escapes instead.]
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?
I think that since string->symbol takes any string, any symbol should be representable in sexprs.
R6RS provides character escapes in symbols 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?
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.
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?
Keep explicit dependencies on supporting the entire Unicode stack out of WG1, IMHO
R6RS provides procedures to explicitly convert strings back and forth between the four Unicode normalization forms. Do we provide any sort of string normalization?
Keep explicit dependencies on supporting the entire Unicode stack out of WG1, IMHO
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?
John Cowan knows his Unicode.
There is the question of the right VCS to use. I prefer Monotone. Currently we are having an email vote on the list. I have entered this ticket to play with the Trac ticketing system. We can finalize the ticket once we have chosen a VCS.