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

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

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 3216 bytes --]

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        cowan@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"

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

[-- Attachment #2: Type: text/html, Size: 3777 bytes --]

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

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 3619 bytes --]

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).

On Wed, Jan 16, 2019 at 9:27 AM John Cowan <cowan@ccil.org> wrote:

> 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        cowan@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"
>
>

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

[-- Attachment #2: Type: text/html, Size: 4514 bytes --]

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

[Per Bothner]

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
per@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-wg2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]

On Thu, Jan 17, 2019 at 8:15 PM Per Bothner <per-ENPyne5uQy1BDgjK7y7TUQ@public.gmane.org> 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        cowan-PrmTNUR8zL8@public.gmane.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

-- 
You received this message because you are subscribed to the Google Groups "chibi-scheme" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chibi-scheme+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to chibi-scheme-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
Visit this group at https://groups.google.com/group/chibi-scheme.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 4680 bytes --]

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

[Ivan Raikov]

I thought the Great Compromise of R7RS was to have specifications for
both a small and a large language, so that everyone is happy (or at
least equally mad :-)) .
Isn't the difference with R6RS that R7RS-large draws extensively on
SRFIs which are indeed attempts to codify existing practices?

On Thu, Jan 17, 2019 at 5:15 PM Per Bothner <per@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
> per@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-wg2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [scheme-reports-wg2] Re: Tangerine Edition penultimate report: how I voted, how you're voting

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 2530 bytes --]

On Fri, Jan 18, 2019 at 3:20 PM Ivan Raikov <ivan.g.raikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <per-ENPyne5uQy1BDgjK7y7TUQ@public.gmane.org> 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
> > per-ENPyne5uQy1BDgjK7y7TUQ@public.gmane.org   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-wg2+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "chibi-scheme" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chibi-scheme+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to chibi-scheme-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
Visit this group at https://groups.google.com/group/chibi-scheme.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 3932 bytes --]

Re: [scheme-reports-wg2] Re: Tangerine Edition penultimate report: how I voted, how you're voting

[Amirouche Boubekki]

[-- Attachment #1: Type: text/plain, Size: 3335 bytes --]

I am satisfied with the approach taken by R7RS of being both small and
large.

Le sam. 19 janv. 2019 à 22:39, John Cowan <cowan-PrmTNUR8zL8@public.gmane.org> a écrit :

>
>
> On Fri, Jan 18, 2019 at 3:20 PM Ivan Raikov <ivan.g.raikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 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 <per-ENPyne5uQy1BDgjK7y7TUQ@public.gmane.org> 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
>> > per-ENPyne5uQy1BDgjK7y7TUQ@public.gmane.org   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-wg2+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "chibi-scheme" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chibi-scheme+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To post to this group, send email to chibi-scheme-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> Visit this group at https://groups.google.com/group/chibi-scheme.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "chibi-scheme" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chibi-scheme+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to chibi-scheme-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
Visit this group at https://groups.google.com/group/chibi-scheme.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #2: Type: text/html, Size: 5304 bytes --]