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

WG1Ballot­Gleckler

aag
2011-06-29 12:47:38
28Changed vote on #28 based on new compromise proposal between Cowan's and Shinn's proposals.history
source

Instructions

WG1 Ballot Items To Finalize by July 1st

Previous Undecided and Re-opened Ballot Items

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

WG1 voted srfi-9 before. New arguments against filter constructors were raised, so the ticket was re-opened.

References:

I had initially voted for SRFI 99 as my top choice, but I'm now convinced that that's just too complicated a system for core Scheme. We need something more fundamental upon which other systems can be built.

However, I don't want to give up convenient syntax, so I've added a new choice, RecordsGleckler, which is simple combination of RecordsCowan and RecordsArcfide. That way, we get both.

SRFI 9 is widely used and is about the simplest syntactic implementation one could hope for. It doesn't support inheritance. As Aaron Hsu has pointed out, it has problems with filtering constructors.

RecordsArcfide is also simple and, while an earlier version supported inheritance, this one doesn't. It is a syntactic system. It uses the name `define-disjoint-type'. It is carefully designed to be forward compatible with the usual record definition system features, e.g. name construction. It is also designed not to have the problems of filtering constructors that are present in SRFI-9.

RecordsCowan is also simple and also supports inheritance. Furthermore, it's a procedural system, which makes more sense as the fundamental approach for WG1, which should be about nailing down simple, clean design for the core ideas. However, even its author doesn't vote for it, preferring SRFI-9 instead.

UniqueTypesSnellPym is a good distillation of the core ideas and is also procedural. However, its handling of subtypes (i.e. the requirement to pass <e> and <d> procedures rather than the supertype itself) and the way that fields are declared to be mutable are both awkward. However, I do agree with the premise stated in the Background section, i.e. that we should provide a mechanism on which other, more powerful and more widely adopted record systems can be built.

AggregatesMedernach is another good distillation of the core ideas. However, constructing its aggregate functions is an all-or-nothing affair; the type switch mechanism seems to require complete destructuring of the record even when not all of the components are necessary, e.g. in the SRFI 9 predicate example; and there is no inheritance.

SRFI 99 (ERR5RS Records) is an extension of SRFI 9 that is a rationalization of the R6RS system, so I'm voting for it ahead of the R6RS system. As the description says, "This entire SRFI is compatible with the procedural and inspection layers of the R6RS record system, but offers several worthwhile improvements over the R6RS system."

Here is exactly how I came up with the preference order above:

cowan > snellpym+inheritance+mutate

because <cowan> is simpler and cleaner

snellpym+inheritance+mutate > medernach snellpym+inheritance+mutate > snellpym+mutate

because inheritance is desirable

cowan > hsu

because it supports inheritance and because procedural is more fundamental than syntactic

hsu > srfi-9

because it eliminates the problems of filtering constructors

medernach > hsu snellpym+inheritance+mutate > hsu snellpym+mutate > hsu

because procedural is more fundamental than syntactic

srfi-9 > wg2 hsu > wg2

because WG1 Scheme should have some form of record definition facility

wg2 > srfi-99

because of the high complexity of SRFI 99, as well as the problems others have reported

srfi-99 > r6rs

because SRFI 99 is a refinement of R6RS records, designed to solve some of their problems

wg2 > r6rs

because of the high complexity of R6RS, as well as the problems others have reported

r6rs > snellpym

because snellpym doesn't support mutation

#28 binary I/O ports

Do we provide any binary input or output ports, and if so how do we construct them and operate on them? Can binary and textual operations be mixed on the different port types?

BinaryPortsCowan provides binary port operations, being a mild revision of the relevant parts of PortsCowan.

PortsShinn provides binary port operations, with similar operations to BinaryPortsCowan but keeping the binary/textual ports disjoint.

R6RS provides an entirely new I/O system, as well as a separate R5RS-compatible I/O system.

The withdrawn SRFI-91 provides yet another I/O system supporting binary ports.

Note this item as well as #29 and #31 specify semi-orthogonal aspects of I/O systems which are typically specified together by individual proposals. If the same proposal doesn't win for all three, the aspects will be merged as needed.

WG1 voted weakly in favor of PortsCowan before.

#83 Auxiliary Keywords

In R6RS auxiliary keywords (such as else in cond and case forms) are explicitly exported from the (rnrs base (6)) library. Do we want to bind and export these from the core library?

If else is bound in the default module, then it must be imported at the call site whenever using it in cond or it won't match hygienically.

If else is not bound in the default module, then it must not be bound or imported at the call site whenever using it in cond or it won't match hygienically.

Another option is to specify for cond and case that they match the else identifier literally, ignoring any hygiene. This breaks compatibility with R5RS and R6RS.

WG1 voted unbound previously. New issues were brought up on the list so the ticket was re-opened.

References:

I just don't understand the issues here well, so I'll leave the debate to others for now.

#3 module naming convention

We need a naming convention for the core modules and standard libraries of the new module system.

The existing break down is based on John Cowan's earlier proposal of factorings in items #71, #72, #73, #74, #75, #76, #77, as well as an I/O module breakdown in PortsCowan. There have been various tickets proposing changing this, so we are re-opening the ticket.

My own proposal, ModuleFactoringGleckler, is a simple combination of ModuleFactoringCowan and ModuleFactoringShinn.

New Ballot Items

WG1 - Core

#85 Blobs, bytevectors, byte-vectors, octet-vectors, or something else?

Now that we have blobs, we have to decide what to call them. R6RS uses bytevector, SRFI-4 and SRFI-68 uses u8vector, while the original WG1 proposal used blob (which is therefore the default).

While "blob" is a widely used term these days, I prefer a properly hyphenated, descriptive term.

#118 Simple literals must be explicitly delimited.

In R5RS syntax such as #t#f is left unspecified - some readers may parse this as the true literal followed by false. R6RS requires identifiers, characters, booleans, number objects, and . to be terminated with a "delimiter" or by the end of input.

References:

#119 Whether to treat # as a delimiter.

In R5RS foo#f is a valid identifier, whereas R6RS requires # to act as a delimiter, so that this would parse as the identifier foo followed by the false literal.

#123 Extend unquote and unquote-splicing to multiple arguments

This is a change also made by R6RS (and CL).

References:

One of the threads above indicates that Alan Bawden approves of this change. I defer to Alan's infinite wisdom in all things related to macros.

#124 Nested quasiquote semantics

References:

#125 Allow procedures not to be locations (making EQV? unspecified in some additional cases)

This is a change also made by R6RS, specifically:

A quasiquote expression may return either fresh, mutable objects or literal structure for any structure that is constructed at run time during the evaluation of the expression. Portions that do not need to be rebuilt are always literal BEFORE is called whenever execution enters the dynamic extent of the call to THUNK and AFTER is called whenever it exits that dynamic extent. Jeronimo Pellegrini scripsit: > According to Section 6.7.1, "Conversely, not all character ports are > binary ports -- for example, the /string ports/ discussed below". It > is not really clear to wether the document *requires* string ports not > to be binary or if it was just an example of a port that *could* be > character but not binary. I haven't thought about it, but I guess it *could* be the latter, if the environment provides a default encoding for string ports. Existing features of IEEE Scheme may be removed only if a strong case can be made that they are fundamentally flawed. Insofar as practical, the language should be backwards compatible with the IEEE standard, the R5RS standard, and an appropriate subset of the R6RS standard. Unfortunately, most programming languages give nondescript names such as DIV(IDE), QUOT(IENT), MOD(ULO), and REM(AINDER) to these operations. The language should make clear to programmers what division operations their programs are performing, especially when negative dividends and divisors can arise, but perhaps may not often arise during testing. [...] The R5RS gives the names quotient and remainder to the truncating division operator pair, and the name modulo to the remainder half of the flooring division operator pair. For all these three procedures in the R5RS, the dividend may be any integer, and the divisor may be any nonzero integer.

On the other hand, we may prefer relegating them to a backward-compatibility module.

Vote "yes" to keep, "no" to remove, and "module" to relegate to a module.

#151 Extend finite? and nan? to non-real values

R6RS specifies the domain of finite? and nan? as the real numbers only. I propose that finite? return #t on a non-real value iff both the real part and the imaginary part are finite and not +nan.0, and that nan? return #t on a non-real value iff either the real or the imaginary part is +nan.0.

#152 exact-integer-sqrt inconsistent with multiple values module

R5RS does not actually specify any procedures which return multiple values, and so the decision to separate multiple values to a module was reasonable. However, we also voted to make exact-integer-sqrt, which is in the base module, return multiple values, namely the root and the remainder. That would make the procedure useless unless multiple values are provided.

We can either make multiple values not a module, make exact-integer-sqrt return a list (or single integer) rather than multiple values, relegate exact-integer-sqrt to a new module, remove it altogether, or do nothing and leave the inconsistency.

#180 Make case and cond clauses into bodies

Andy Wingo suggests: make the clauses in case and cond forms (without =>, naturally) be BODY instances, to allow them to have definitions. It is well defined AFAIK, and costs nothing.

The counter-argument is that it doesn't "look" like the sort of place definitions are allowed.

Ugly, and let's not extend the language beyond common practice in trivial areas like this.

#181 Add WHEN and UNLESS to the base module

#182 Add WHILE and UNTIL

These trivial syntaxes add familiarity for new Scheme programmers coming from other languages, as will almost always be the case. LOOP is too big and named-LET too alien.

These go against the grain of the language. Are they even widely supported?

#183 Escaped newline removes following whitespace?

Andy Wingo suggests the R6RS handling of escaped embedded newlines:

"asdadf \ asdfadf"

in R6RS has the same meaning as "asdf asdfadf". It allows you to nicely indent strings that you need to line-break for width. I suggest that the production

\ NEWLINE WHITESPACE*

within string literals be elided.

Note an alternate method for handling embedded strings with nice indentation is scribble syntax.

We voted on various string syntaxes previously but did not specifically propose this R6RS extension. We should have a rationale if we don't follow it.

#184 Require CHAR=?, STRING=? etc. to accept arbitrary numbers of arguments?

R5RS makes a point of specifying that supporting more than two arguments is optional. (Everything not explicitly mentioned is optional, so this may have significance.) R6RS requires accepting 2 or more arguments. Currently Racket, Gambit, Guile, Chez, Ikarus, Larceny, Ypsilon, Mosh, and Scheme 9 support the feature, whereas Gauche, MIT, Chicken, Bigloo, Scheme48/scsh, Kawa, SISC, Chibi, STklos, and SSCM don't.

#185 Add sixth "centered" division operator

From the Guile manual:

— Scheme Procedure: centered/ x y — Scheme Procedure: centered-quotient x y — Scheme Procedure: centered-remainder x y

These procedures accept two real numbers x and y, where the divisor y must be non-zero. centered-quotient returns the integer q and centered-remainder returns the real number r such that x = q*y + r and -|y/2| <= r < |y/2|. centered/ returns both q and r, and is more efficient than computing each separately.

Note that centered-quotient returns x/y rounded to the nearest integer. When x/y lies exactly half-way between two integers, the tie is broken according to the sign of y. If y > 0, ties are rounded toward positive infinity, otherwise they are rounded toward negative infinity. This is a consequence of the requirement that -|y/2| <= r < |y/2|.

Note that these operators are equivalent to the R6RS operators div0, mod0, and div0-and-mod0.

--Andy Wingo

Taylor Campbell thinks these are useless. We should probably have use cases for _any_ division operator we include.

#195 Editorial: proposed rewording for begin

The documentation for `begin' specifies that it is a sequential construct; but really it splices as well, and also of course it's a keyword for the module system currently. This is inaccurate of the spec to say that "begin is for sequencing".

Suggestion: adopt the language of R6RS section 11.4.7.

--Andy Wingo

We should explain somewhere the four kinds of begins: (begin expr ...), (begin decl ...), top-level begin, and module-top-level begin. Note that R7RS like R5RS does not have (begin decl ... expr ...).

Vote yes to adopt the R6RS description, modified for differences in the language.

#198 Make it an error for a procedure mapped by MAP and friends to mutate the result list/string/vector

This is possibly difficult to enforce, and can break existing R5RS programs written in very bad style.

#199 Make it an error for a procedure mapped by MAP and friends to return more than once

This is possibly difficult to enforce, and can break existing R5RS programs.

#200 Completing the blob procedures

Add blob, blob-map, blob-for-each, and blob conversion functions to and from lists/vectors/strings.

#205 Roll partial-blob-copy(!) into blob-copy(!)

... with extra arguments.

#206 Provide read-syntax for blobs

R6RS provides a #vu8(...) read-syntax for bytevectors. SRFI-4 uses #u8(...).

#207 Editorial: Polar complex numbers are inexact

Add a note saying that 1@2 and (make-polar 1 2) MAY evaluate to an inexact complex number.

#208 Is || a valid identifier?

The grammar in 7.1.1 allows || as an <identifier>. However, page 5 suggests the |...| form is only for convenience (e.g. |foo bar| is equivalent to foo\x20;bar). There's no way to normalise || to anything without the vertical bars that's a valid identifier. Was that intentional, or should the rule be

<vertical bar> <symbol element>+ <vertical bar>

Vote remove to remove the |...| syntax altogether.

#191 Include CLOSE-PORT ?

Should we include close-port, as a generic version of close-input-port and close-output-port?

#188 Clarify wording of and and or definitions

The definitions of and and or may be slightly confusing. Reword them to be more clear. One possible hiccup is that the current language permits the return of different false values, while a clearer wording may preclude this.

R6RS provides a clearer definition that does not provide wiggle room for multiple false values. Should we use that?

I don't see any reason we should have to vote on whether to make things clearer. However, I don't see any reason to worry about permitting different false values.

#187 Clarify duplicate bindings in let*

The language of the standard could clarify that duplicate bindings are permitted in the clauses of a let*.

#215 initial value argument to make-blob

make-blob should either have an initial value argument, or rationale why it is inconsistent with make-vector and make-string.

Vote yes for an initial value argument.

#216 Controlling use of reader labels on output

There are cases when one does not want to output reader labels for shared structure, such as when you don't care (and want the output to be more legible), or when you know that the time or space requirements to construct the table will be too large.

We could offer a parameter to control this, or have a separate procedure (e.g. write/simple) which doesn't use the reader labels.

Finer grained control may also let use specify a predicate for which values are interesting (e.g. never use labels for strings), or only use labels for cycles, etc.

However, I don't like the name. I'd prefer `write-simple', write-simply', or write-without-reader-labels'.