Taylan Ulrich Bayırlı/Kammer scripsit:

> Firstly, R5RS didn't have libraries.

It didn't have formal library machinery, but it certainly had libraries.
Consider the SRFI 1 library.

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

I consider that a trivial use of lists.  In Racket, lists are replaced
by immutable lists in this use.  It would not seriously derange the
character of Scheme to use an opaque object instead, or even to limit
the consumption of rest-arguments to specialized syntax which forces
procedures to either consume all their arguments individually or to
tail-pass unconsumed ones to another such procedure.  (I thought Henry
Baker had written this idea up, but I can't find it.)  That allows you
to just put the arguments on a calling stack without consing.

Not that I would propose this -- it's not Scheme.  I'm just trying to
show that the supposed specialness of lists is a historical artifact,
not something inherent to lists.

> You don't want to have a core pair API and let the lists API be a
> third-party library

No.  But on your principles you seem content to let a few list
procedures be standardized and leave other extremely useful ones in an
unstandardized library.  I approve of SRFI 1 being standardized, and I
want to see it become part of the R7RS-large standard, because I think
it should receive the same treatment as the R7RS-small list API (modulo
import statements).

> pair?/cons/car/cdr can't be implemented sanely in portable library
> code,

Actually, they can be: on top of SRFI 9.

> This can be contrasted to SRFI-113, which isn't fundamental in any
> way,

I still don't understand this claim.  Why aren't sets every bit as
fundamental to programming as hash tables are?  It's true that they can
be implemented on top of hash tables, but SRFI 113 does not require
this.  For that matter, in ImmutableDataStructuresWortman maps are
implemented on top of sets.

> There is no reason to spend time on its specification as a standard
> because it has nothing to gain from being in a standard.

Specifications never have anything to gain from being in a standard.  It
is we, the programmers, who gain from having fundamental data structures
as part of our standards, for the reasons I have given.  Even if lists
were not wired into the Scheme calling convention, they would still be
fundamental data structures.

> 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, on the other hand, do want it or something like it (modulo pointers)
to become part of a standard.  C-compatible structures are another
fundamental data type, and programmers should have them available.

As for standardizing bad APIs, the only way to overcome that risk is
never to change the standard at all, and simply declare that existing
APIs are good by fiat.  There is an argument that on modern systems,
linked lists are a bad API and shouldn't exist, but I don't care: if
code containing them is a problem for you, don't use them.

> Why expect systems to individually support SRFI-113, when any user can
> just download the de-facto sets&bags library from snow-fort.org?

Maybe this is where we are talking past one another.  As far as I am
concerned, saying "To support (scheme sets), download the implementation
from snow-fort.org" *counts* as individually supporting SRFI 113.  If
that didn't work, however, then the implementation could not claim to
support R7RS-large (assuming that included SRFI 113).

> The portable SRFI-69 implementation is bad because it tries to
> implement a feature in Scheme which should be implemented on the low
> level.

That's an implementation-specific perception.  Implementers have limited
time and energy, and if they choose not to provide implementation-specific
machinery to do hash tables, that's a valid choice.  Efficiency is not
a divinely required attribute of implementations.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Real FORTRAN programmers can program FORTRAN in any language.  --Ed Post