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