[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Zelphir Kaltstahl
Subject: Re: Tangerine Edition penultimate report: how I voted, how you're, voting (John Cowan)
Date: Wed, 16 Jan 2019 21:34:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

On 1/16/19 6:00 PM, address@hidden wrote:
> Message: 2
> Date: Wed, 16 Jan 2019 09:27:50 -0500
> From: John Cowan <address@hidden>
> To: address@hidden,
>       address@hidden,         chicken chicken
>       <address@hidden>, address@hidden,
>       address@hidden, guile-user <address@hidden>,
>       address@hidden
> Subject: Tangerine Edition penultimate report: how I voted, how you're
>       voting
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset="UTF-8"
> 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 address@hidden 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"
I am not sure I have a sufficiently informed opinion about SRFIs and
such things. How experienced should a person be, as to not simply vote
for something that superficially might sound great, but actually isn't
so good and screw up the voting?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]