chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] Tangerine Edition penultimate report: how I voted, h


From: John Cowan
Subject: Re: [Chicken-users] Tangerine Edition penultimate report: how I voted, how you're voting
Date: Thu, 17 Jan 2019 22:34:52 -0500



On Thu, Jan 17, 2019 at 8:15 PM Per Bothner <address@hidden> 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        address@hidden
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


 


reply via email to

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