Notes about results:
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.
Seriously. I have not had enough time to digest the various proposals on this topic. And I find it unfortunate that the voting system forces me to express an opinion on topics which I have not fully evaluated just to make sure that i give sufficient weight to my *actual* vote.
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?
This is essentially a strong *NO* vote. Again, I feel that this voting system here inapropriately conflates two issues: whether we should *have* such an interface, and *if* we should have such an interface, what shape it should have.
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?
This is essentially a strong *NO* vote. Again, I feel that this voting system here inapropriately conflates two issues: whether we should *have* such an interface, and *if* we should have such an interface, what shape it should have. It is particularly frustrating to express any positive preference over what is essentially a binary issue just to give sufficient weight to my *no* vote.
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.
Again with a binary issue including a multi-valued one. In this case, however, I am in favor of the proposal because there should be no way to inadvertantly throw a built-in into an infinite loop.
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?
The text above seems to incorrectly indicate a #7 from the previous ballot...
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?
Doesn't dotted-tail == both? It certainly seems so from the syntax used above.
R6RS introduced the concept of mantissa widths as an alternative to the R5RS #s in numbers. Do we want either or both of these?
Don't break my R5RS code & data files!
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.
There may actually be no good answer to this issue. Usually I am against case-folding, but it *is* useful to have when talking about code, and relying on case to distinguish identifiers is arguably moderately evil.
R6RS provides support for #; nested sexp comments, and #| ... |# nested block comments. Do we include either or both of these?
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.
There are some artificial dichotomies introduced in this ballot item. My preferred solution includes all of the above, actually; with agnostic/core, generic/core, separate/module and specific/module.