John Cowan <xxxxxx@mercury.ccil.org> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> RnRS/SRFIs should specify what cannot be simply implemented as a
>> portable library.
>
> I profoundly disagree, and I think almost the whole history of Scheme
> is on my side.
>
> If that rule had applied to the R5RS pair API, it would consist of:
> pair?, cons, car, cdr, set-car!, set-cdr!, null?.  It would exclude:
> cxr procedures, list?, list, length, append, reverse, list-tail, list-ref,
> memq, memv, member, assq, assv, assoc.  In short, some 85% of the R5RS
> API.  And of course 100% of SRFI 1.
>
> So why do we include procedures like `length`?  For programmers, it's
> so it'll just Be There.  It's ready for instant use on any conforming
> platform.  You don't have to decide what to call it.
> By the same token, anyone reading your code sees `length` and (modulo a
> redefinition) already knows what it does.  The same applies to `fold`,
> once you learn it.

Firstly, R5RS didn't have libraries.

Secondly, lists are fundamental to Scheme on a deep level, as for
instance (lambda (foo bar . rest) ...) will use a list to represent the
rest arguments.

Thirdly, the pair API and list API belong together, akin to how the
hashing API and hash table API.  You don't want to have a core pair API
and let the lists API be a third-party library, similar to how you don't
want to specify hashing and let people implement hash tables in Scheme.

(That's not a very good analogy because there's more good reasons to
implement hash tables entirely on the low-level, whereas list procedures
can indeed always be implemented as Scheme code in terms of the pair
procedures and some implementations really do that, but I hope the point
I'm trying to make is clear: it's silly to specify a core data type API
without *any* utility procedures and offload all utility procedures to a
third-party library.  A better analogy might involve the core procedures
in SRFI-126 vs. all the utility procedures in it.)

If we had libraries earlier, and if lists weren't so fundamental, it
would have been conceivable to put the whole pair/list API into a
standard list library.  Then that *would* need standardization though,
since pair?/cons/car/cdr can't be implemented sanely in portably library
code, and the list utility procedures would be specified alongside, akin
to how SRFI-126 defines a bunch of utility procedures while it's already
specifying the whole hashtable API.

This can be contrasted to SRFI-113, which isn't fundamental in any way,
and can be implemented *entirely* as portable library code.  There is no
reason to spend time on its specification as a standard because it has
nothing to gain from being in a standard.  (Its own development could be
"specification driven" but that's a different topic.)

Note for instance how https://github.com/TaylanUB/scheme-bytestructures
is implemented as a portable library.  (Though it would benefit from a
standardized FFI API.)  I don't want the API of this library to ever
become a standard, because it has nothing to gain from it, and it would
entail the risk of standardizing a bad API.  I still have responsibility
as a library author to keep backwards compatibility and all, but one
should not expect the same amount of rigor on that matter from a library
author, as from the specification of the whole programming language.

And let me expand on the parenthesis of the last paragraph: my library
would benefit a *ton* from a standardized FFI API.  Because I cannot
implement an FFI as portable library code.

> That's why the work of defining SRFIs, even when completely portable,
> is valuable.  Any system that implements the SRFI (and if it *is*
> completely portable, that's any system) provides predefined
> functionality using predefined names.  If you want sets (and
> programmers often do want sets), and you have SRFI 113 available, you
> *have* sets.  And the names were chosen (to the best of my ability) so
> that you pretty much know how to use them if you know R7RS-small and
> SRFI 1.  It is a comprehensive package in order to avoid the Curse of
> Lisp <http://www.winestockwebdesign.com/Essays/Lisp_Curse.html>; see
> also the rationale of SRFI 1.

Why expect systems to individually support SRFI-113, when any user can
just download the de-facto sets&bags library from snow-fort.org?  All
advantages of being "just there" (sans the need to install a package),
having familiar names, and everything apply.  No need to make a standard
out of it.

When the standard is really good, it won't hurt either.  But as it
stands we have little resources, and they should not be spent on
standardizing something that could live as a library just as well.

>> OTOH a hash table API is important because you can't implement it in
>> portable Scheme in terms of a more fundamental feature.
>
> And yet there *are* portable implementations of hash tables that provide
> exactly that.

The portable SRFI-69 implementation is bad because it tries to implement
a feature in Scheme which should be implemented on the low level.  It's
akin to implementing pairs with lambda and all that silly stuff.  In
particular, it implements hash-by-identity as hash.  That's a change
from constant time to linear time for eq? hash tables wrt. the key size.

Taylan