<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 17, 2019 at 8:15 PM Per Bothner <<a href="mailto:per@bothner.com" target="_blank">per@bothner.com</a>> wrote:<br></div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For the record, I'm extremely leery of the more-is-better approach.<br>
We seem to be adding a large number of very large APIs, which seems<br>
to be contrary to the Scheme ideal of small well-chosen primitives<br>
that work synergistic well together. </blockquote><div><br></div><div>I don't believe that that idea ever applied to the Scheme library, otherwise</div><div>the list primitives would have been pair?, car, cdr, cons, null?, set-car!, and</div><div>set-cdr!, and possibly not even the last two.</div><div><br></div><div>Allow me to quote the first paragraph of Olin Shivers's rationale for SRFI 1, itself</div><div>a "very large API" of 149 procedures, especially when compared to the</div><div>7 minimal procedures above and the 50 R6RS procedures, yet SRFI 1 is</div><div>very popular and 24 of the 32 Schemes for which I have SRFI data</div><div>implement it.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>The SRFI 43 rationale (by Taylor Campbell) begins similarly:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>Finally, here's Olin again in SRFI 33, bitwise operations:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If you believe in "small is beautiful," then what is your motivation </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> for including anything beyond BITWISE-NAND?</blockquote><div> </div><div>Quant. suff.</div><div><br></div><div>-- </div><div><div>John Cowan          <a href="http://vrici.lojban.org/~cowan">http://vrici.lojban.org/~cowan</a>        <a href="mailto:cowan@ccil.org">cowan@ccil.org</a></div><div>You are a child of the universe no less than the trees and all other acyclic</div><div>graphs; you have a right to be here.  --DeXiderata by Sean McGrath</div></div><div><br></div><div><br></div><div> </div><div><br></div></div></div></div></div></div></div></div>