seeds Alex Shinn 08 Oct 2015 05:03 UTC
Re: seeds taylanbayirli@xxxxxx 08 Oct 2015 07:55 UTC
Re: seeds Arthur A. Gleckler 08 Oct 2015 17:46 UTC
Re: seeds taylanbayirli@xxxxxx 08 Oct 2015 19:38 UTC
Re: seeds Arthur A. Gleckler 08 Oct 2015 21:47 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 08:09 UTC
Re: seeds Kevin Wortman 09 Oct 2015 17:18 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 18:33 UTC
Re: seeds Kevin Wortman 13 Oct 2015 17:36 UTC
Re: seeds taylanbayirli@xxxxxx 13 Oct 2015 18:28 UTC
Re: seeds Alex Shinn 14 Oct 2015 01:59 UTC
Re: seeds taylanbayirli@xxxxxx 14 Oct 2015 09:09 UTC
Re: seeds taylanbayirli@xxxxxx 14 Oct 2015 10:06 UTC
Re: seeds Alex Shinn 16 Oct 2015 01:23 UTC
Re: seeds taylanbayirli@xxxxxx 16 Oct 2015 13:34 UTC
Re: seeds Alex Shinn 16 Oct 2015 23:48 UTC
Re: seeds taylanbayirli@xxxxxx 17 Oct 2015 12:08 UTC
Re: seeds Alex Shinn 17 Oct 2015 13:12 UTC
Re: seeds taylanbayirli@xxxxxx 17 Oct 2015 14:09 UTC
What SRFIs are for John Cowan 17 Oct 2015 14:41 UTC
Re: What SRFIs are for taylanbayirli@xxxxxx 17 Oct 2015 15:56 UTC
Re: What SRFIs are for John Cowan 17 Oct 2015 16:55 UTC
Re: What SRFIs are for taylanbayirli@xxxxxx 17 Oct 2015 18:08 UTC
Re: What SRFIs are for John Cowan 17 Oct 2015 18:51 UTC
Re: seeds John Cowan 15 Oct 2015 17:49 UTC
Re: seeds Alex Shinn 09 Oct 2015 02:54 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 07:59 UTC
Re: seeds John Cowan 15 Oct 2015 17:51 UTC
Re: seeds taylanbayirli@xxxxxx 15 Oct 2015 23:08 UTC
Re: seeds John Cowan 16 Oct 2015 13:09 UTC
Re: seeds taylanbayirli@xxxxxx 16 Oct 2015 14:01 UTC

Re: What SRFIs are for taylanbayirli@xxxxxx 17 Oct 2015 15:56 UTC

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