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

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

A formal library machinery is what makes the difference.

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

Historic artifact or not, it has always been the case that lists are the
"fallback" data type, one of the most fundamental ones for Scheme.  Sets
and bags are on a different planet.

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

I am *not* content on standardizing the most minimal set of procedures
that need low-level implementations, as a substantial part of my mail
was trying to explain.  See also my criteria for inclusion of utility
procedures in SRFI-126.  Were hashtables not in need of being
implemented at the low-level though, then *all* of SRFI-126 would be a
third-party library, like Bytestructures.

Specifying a minimal API can be a good "emergency measure" though,
e.g. IMO it would have been better for R7RS-small to define *some* hash
table API, and I still greatly fear writing a bad specification for some
of the utility procedures in SRFI-126, but all in all it's better for
the commonly used ones to be there in the same library.

The question is not whether we do or don't define utility procedures in
a library.  The question is whether the fundamental feature offered by
the whole library itself is in need of standardization, or whether the
whole library can just be a third-party portable library.

>> pair?/cons/car/cdr can't be implemented sanely in portable library
>> code,
>
> Actually, they can be: on top of SRFI 9.

Indeed, I forgot.  It's mostly just them being so central in the history
of Lisp and Scheme what gives them their special position.

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

Indeed, one can implement sets and bags with binary trees or else as
well.  In the grand scheme of things, it might not be bad to have a
specification for them that's truly independent of implementation, but
there is really no emergency for this.  An explicitly hashtable based
de-facto library is sufficient.

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

To me as a programmer, it is absolutely irrelevant whether there's an
SRFI behind the de-facto sets&bags library I download from snow-fort.

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

There is no need to *overcome* the risk of standardizing bad APIs, only
not to cause that risk to apply in a spurious amount of standardized
libraries which could have as well been third-party libraries.

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

So the difference between making it an SRFI or not is practically going
to be whether it's the user or the implementor who downloads the
library.  That is precisely why I say it's useless to make an SRFI out
of it, in a time we should be specifying interfaces that really are in
need of it.

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

I could argue against that but let me instead just point out that the
portable SRFI-69 implementation can't use procedures as keys in hash
tables, and that its hash-by-identity doesn't actually hash by identity;
mutating an object will change its "identity" as far as that
implementation is concerned.  It's simply broken.

You cannot implement eq? and eqv? hash tables portably, plain and simple.

Taylan