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:17 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 John Cowan 17 Oct 2015 18:51 UTC

Taylan Ulrich Bayırlı/Kammer scripsit:

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

The criteria look good, although they depend on empirical factors (what
is actually used?) that we probably don't really have evidence for.

> e.g. IMO it would have been better for R7RS-small to define *some*
> hash table API,

That was voted on in <http://trac.sacrideo.us/wg/wiki/WG1Ballot2Results>
(ticket #36) and shot down, apparently because people thought a limited
implementation was worse than none.  I didn't think, given the conflict
between SRFI 69 and R6RS, that either had a chance of making it into
R7RS-small.

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

SRFI 113 is, I contend, independent of implementation.

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

It's relevant because if there's a SRFI, you know that any Scheme
claiming to support that SRFI will be able to run your code one way
or another.  A fortiori, if it's part of R7RS-large, you know that
any R7RS-large Scheme will be able to run your code as well.  You may
need some particular implementation-specific incantation to make your
implementation SRFI-compliant or RnRS-compliant, or you may not.

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

For one thing, the cost of SRFI 113 is sunk, and while the cost of
considering it as part of R7RS-large is not yet sunk, it is small
compared to the cost of writing it.

For another, I strongly encourage anyone to write SRFIs that specify
interfaces that "really are in need of it."  Attention is a scarce
resource, but positive integers are not.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Would your name perchance be surname Puppet, given name Sock?
                --Rick Moen