Tangerine Edition penultimate report: how I voted, how you're voting

[John Cowan]

Well, there are two weeks to go on the Tangerine Edition ballot (cutoff is 12 noon UTC on Saturday, February 2).  So far, 18 people have voted, including me.  For the Red Edition we had 30 voters, so I hope some of you who haven't voted yet will take an interest and give us your views.  Remember that you don't have to vote on all issues: choosing "No vote" is equivalent to abstaining, which does not affect the outcome, as votes are decided by a majority of the votes cast.

As in the Red Edition, the choice of string library (issue #1) has been the most controversial.  There was no majority vote cast in the Red Edition, so the issue is being reballoted.  Currently, the index-based SRFI 152, which is meant to be a simple basic string library, holds a majority position, but only by a single vote.  There is a strong minority for the original SRFI 13, which is a superset (with a few deviations) of 152.  SRFI 130, which is cursor-based, has only a single vote.  Three write-in votes were cast for SRFI 140, which I excluded from Tangerine because it provides adjustable-length strings.  These, like all other features that can't be implemented (at least minimally) on top of R7RS-small, have been postponed to the Green Edition.  I voted for SRFI 152.

Issue #4, supplementing the Red Edition's SRFI 127 generators with their dual, accumulators, is substantially beating the alternatives of status quo and no library.  Issue #6 is about bitwise operations on integers, and the comprehensive SRFI 151 is dominating the R6RS alternative.  The same thing is happening with fixnums (issue #7) and flonums (issue #8), where SRFIs 143 and 144, both supersets of R6RS, are getting more support than the R6RS alternatives. SRFI 160 is a superset of SRFI 4 that provides homogeneous vectors (issue #10), and it too is winning, though by a lesser margin.  Surprising to me is that for the combinator-based formatting library (issue #11), the combinator-based SRFI 159 is in a majority position over SRFI 48, the traditional template-based (as in Common Lisp) alternative.  Essentially all the remaining issues are yes/no/abstain, and yes is dominant all down the line, though a little less so for ratios (issue #13) and exact complex numbers (issue #16).  I voted with the majority for all of these except exact complex numbers.

So what is happening is that people are voting for more rather than less, as with the Red Edition.  This encourages me that I'm going in a sensible direction with the large language.

-- 

John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org

It was dreary and wearisome.  Cold clammy winter still held sway in this

forsaken country.  The only green was the scum of livid weed on the dark

greasy surfaces of the sullen waters.  Dead grasses and rotting reeds loomed

up in the mists like ragged shadows of long-forgotten summers.

        --LOTR, "The Passage of the Marshes"

[John Cowan]

Sorry, left out the voting link this time:  it's http://tinyurl.com/tangerine-ballot for the vote, and http://tinyurl.com/orange-straw-poll for the Orange Edition straw poll (guidance to the editor on what should appear in the next poll).

[John Cowan]

On Thu, Jan 17, 2019 at 8:15 PM Per Bothner <p...@bothner.com> wrote:

For the record, I'm extremely leery of the more-is-better approach.
We seem to be adding a large number of very large APIs, which seems
to be contrary to the Scheme ideal of small well-chosen primitives
that work synergistic well together. 

I don't believe that that idea ever applied to the Scheme library, otherwise

the list primitives would have been pair?, car, cdr, cons, null?, set-car!, and

set-cdr!, and possibly not even the last two.

Allow me to quote the first paragraph of Olin Shivers's rationale for SRFI 1, itself

a "very large API" of 149 procedures, especially when compared to the

7 minimal procedures above and the 50 R6RS procedures, yet SRFI 1 is

very popular and 24 of the 32 Schemes for which I have SRFI data

implement it.

The set of basic list and pair operations provided by R4RS/R5RS Scheme is far from satisfactory. Because this set is so small and basic, most implementations provide additional utilities, such as a list-filtering function, or a "left fold" operator, and so forth. But, of course, this introduces incompatibilities -- different Scheme implementations provide different sets of procedures.

The SRFI 43 rationale (by Taylor Campbell) begins similarly:

R5RS provides very few list-processing procedures, for which reason SRFI 1 (list-lib) exists. However, R5RS provides even fewer vector operations — while it provides mapping, appending, et cetera operations for lists, it specifies only nine vector manipulation operations —: [list omitted] .  Many Scheme implementations provide several vector operations beyond the miniscule set that R5RS defines (the typical vector-append, vector-map, et cetera), but often these procedures have different names, take arguments in different orders, don't take the same number of arguments, or have some other flaw that makes them unportable. For this reason, this SRFI is proposed.

Finally, here's Olin again in SRFI 33, bitwise operations:

If you believe in "small is beautiful," then what is your motivation 

for including anything beyond BITWISE-NAND?

 

Quant. suff.

-- 

John Cowan          http://vrici.lojban.org/~cowan        co...@ccil.org

You are a child of the universe no less than the trees and all other acyclic

graphs; you have a right to be here.  --DeXiderata by Sean McGrath

 

[John Cowan]

On Fri, Jan 18, 2019 at 3:20 PM Ivan Raikov <ivan.g...@gmail.com> wrote:

 

Isn't the difference with R6RS that R7RS-large draws extensively on
SRFIs which are indeed attempts to codify existing practices?

SRFIs don't always codify existing practice, including the SRFIs drawn on

in past, present, and future R7RS-large ballots.  The original intention of the

Steering Committee, I think, had nothing to do with SRFIs; I simply decided

when writing the charter (which the committee approved) to leverage both

existing and to-be-written SRFIs in order to be able to create R7RS-large

piecemeal, which has always seemed to me the only practical approach.

That said, SRFIs often do refer to existing implementations, or implementations

of languages other than Scheme.

 

On Thu, Jan 17, 2019 at 5:15 PM Per Bothner <p...@bothner.com> wrote:

>
> On 1/16/19 6:27 AM, John Cowan wrote:
> > So what is happening is that people are voting for more rather than less, as with the Red Edition.  This encourages me that I'm going in a sensible direction with the large language.
>

> For the record, I'm extremely leery of the more-is-better approach.
> We seem to be adding a large number of very large APIs, which seems
> to be contrary to the Scheme ideal of small well-chosen primitives

> that work synergistic well together.  People were unhappy with R6RS
> because of its size and that so much of it was invention rather than
> codifying existing practice.  R7RS-large is the same - but much more so.
> --
>         --Per Bothner
> p...@bothner.com   http://per.bothner.com/
>

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.