Tangerine Edition final results available

[John Cowan]

Voting is now closed on the Tangerine Edition ballot and the accompanying
Orange Edition straw poll.  My thanks to the 29 Schemers who weighed in on
what will be part of the Tangerine Edition, as well as the 17 Schemers who
provided feedback on what should and should not appear on the Orange
Edition ballot.  Note that proposals passed by a majority of the votes
cast: "no vote" did not count one way or another.

The raw votes are available as Google spreadsheets at <
http://tinyurl.com/tangerine-results> and <
http://tinyurl.com/orange-straw-results).  The Chair edited Vincent Manis's
vote from "no vote" to "SRFI 152" at his own request.

The following nine SRFIs passed with resounding majorities:

SRFI 115 (combinator-based regular expressions)
SRFI 141 (comprehensive integer division operators)
SRFI 143 (fixnum operators)
SRFI 144 (flonum operators, R6RS plus <math.h>)
SRFI 146 (persistent tree and hash mappings)
SRFI 151 (comprehensive bitwise operations on integers)
SRFI 158 (backward-compatible additions to SRFI 127 on generators)
SRFI 159 (combinator formatting)
SRFI 160 (comprehensive homogeneous vector library, including
inexact-complex vectors)

The sample implementation of SRFI 160 is not yet written: however, the API
has mostly stabilized, excluding u1vectors (bitvectors) from consideration
and adding a (srfi 160 base) library that provides SRFI 4 support for all
SRFI 4 vector types plus the complex types.

The R6RS library (rnrs bytevectors) was adopted into Tangerine, also by a
large majority.  Implementors should note that "must" when applied to a
procedure or macro argument means only "it is an error unless"; actually
signaling an error is not required.  In addition, there are corrections at <
http://www.r6rs.org/r6rs-errata.html>, including substantive changes to the
`utf16->string` and `utf32->string` procedures.  A portable R7RS-small
implementation of this library written by Will Clinger can be found at
snow-fort.org and in the contrib/cowan subdirectory of the SRFI 4
repository.

Required support for the full numeric tower, including bignums up to an
implementation-defined limit, ratios (exact non-integers), inexact numbers,
and complex (non-real) numbers both exact and inexact, is also part of
Tangerine. There are no such requirements in R7RS-small. Note that while
most numeric types were uncontroversial,  exact complex numbers passed by
just one vote.  (See  <
http://mentalfloss.com/article/59873/10-elections-decided-one-vote-or-less>
for other elections decided by a single vote.)

Finally, the vote on the string library was problematic.  Out of 26 votes
cast, a one-vote majority of 14 voted for SRFI 152, a simple index-based
string library.  However, rather than accepting the Will of the People in
this particular case, your Chair has decided to disregard this vote and
postpone the choice of a string library to the Green Edition.  Anyone who
wishes to appeal against this decision should post to <
address@hidden>, and if anyone does, a vote will be
taken on that list whether to sustain the Chair's decision (no string
library yet) or override it (SRFI 152 becomes the string library).

Why am I doing this?  There were 6 votes for the original SRFI 13, of which
SRFI 152 is a subset.  There were 3 votes  for the cursor-based SRFI 130,
which its author has offered to rewrite (as a new SRFI) to remove some
substantive objections to it.  SRFI 140, which splits Scheme strings into
mutable and immutable subtypes, also received 3 write-in votes: I had
excluded it from the ballot because it cannot be portably implemented on
top of R7RS-small, and non-portable SRFIs are collected in the Green
Edition.  For that reason, string libraries will be revoted then.  (In the
Red Edition, no proposal obtained a majority.)

As is traditional, the Chair is giving the new libraries their official
names.  The names corresponding to the SRFIs in the order listed above
are:  (scheme regex), (scheme division), (scheme fixnum), (scheme flonum),
(scheme mapping) and (scheme mapping hash), (scheme bitwise), (scheme
generator), (scheme format), and (scheme vector @), where @ is a
metasyntactic variable for any of {base, u8, s8, u16, s16, u32, s32, u64,
s64, f32, f64, c64, c128}.  The (rnrs bytevectors) library will be known
within R7RS-large as (scheme bytevector): note the change from plural to
singular to conform with other R7RS library names.

The (scheme mapping hash) library has fewer operations than the (scheme
mapping) library, but is usable with unordered data types provided a good
hash function can be written for them.

This decision supersedes within R7RS-large the Red Edition's definition of
(scheme generator) as SRFI 158.  This should affect nobody except people
who have used one of the 19 new identifiers for some other purpose, in
which case import exclusion is at their service.

Of the nine libraries asked about on the Orange Edition straw poll, all
were well-supported (with volunteers to implement some of them) except the
prime number library at <
https://bitbucket.org/cowan/r7rs-wg1-infra/src/default/PrimesGauche.md>.
There was also a one-vote majority against the TalliesCowan (descriptive
statistics) library, but as there is a volunteer to implement it, I'll
leave it on the docket for now.

-- 
John Cowan          http://vrici.lojban.org/~cowan        address@hidden
weirdo:    When is R7RS coming out?
Riastradh: As soon as the top is a beautiful golden brown and if you
stick a toothpick in it, the toothpick comes out dry.