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

[John Cowan <cowan-PrmTNUR8zL8@public.gmane.org>]

[-- 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 --]