Email list hosting service & mailing list manager


SRFI 116 issues discussed on the scheme-reports list John Cowan 17 Sep 2014 17:09 UTC

The following issues were discussed on the scheme-reports mailing list.  See
<http://lists.scheme-reports.org/pipermail/scheme-reports/2014-September/thread.html>
for full text.

1. These procedures should take SRFI 114 comparators instead of equality
predicates?

Rejected.  This library is meant as a drop-in replacement for SRFI 1 in
most contexts (see issue 7 below).  So the relevant procedure arguments
woul have to be polymorphic in procedures and comparators, causing an
inherent slowdown.

2.  First, second, third, etc. should be restored (they were not present
in the first draft of this SRFI).

Accepted.

3. Xipair (the analogue of SRFI 1 xcons) should be removed in favor of
a general flip operator in another SRFI.

Rejected.  I am in favor of such a SRFI, but want to keep xipair for
SRFI 1 compatibility.

4.  Lists as sets should be removed in favor of a SRFI based on immutable
tree-like sets.

Accepted.

5.  Iqq (immutable quasiquote) should be added.

I don't object to this in principle, but don't feel up to implementing
it either.  If someone will supply an implementation, I'll add it.

6.  Remove ic*r procedures other than icaar, icadr, icdar, icddr,
based on the R7RS-small precedent of putting them in a separate library
(scheme cxr).

Rejected on drop-in replacement grounds.

7.  There shouldn't be different interfaces for mutable and immutable
pairs.

Rejected.  Immutable pairs are unfortunately not *entirely* a drop-in
replacement for mutable pairs, at least not without breaking R5RS and
R7RS-small.  In particular, tail argument lists passed to procedures
are guaranteed to be freshly allocated and mutable.  Thus, the standard
`list` procedure can be defined as (lambda list list), and portable
programs need access to both mutable and immutable pairs.

That said, it is probably worthwhile in the R7RS-large context to make
a version of (scheme base) that imports the immutable procedures instead
and imports the mutable equivalents Racket-style as mcar, mcdr, mcons ....
However, that is an R7RS issue rather than a SRFI 116 issue.

8. () should not be shared between mutable and immutable lists.

Rejected.  The immutable lists of this SRFI are meant to work like
mutable lists, and there is no reason to duplicate (), since both
versions are immutable.  What's actually anomalous is that () is
immutable whereas all other standard lists are mutable, but that ship
sailed half a century ago.  There will be a future SRFI for truly mutable
sequences which may be of zero length without losing their identity:
see <http://trac.sacrideo.us/wg/wiki/QueuesCowan> for a preliminary draft.

9. Circular lists should be restored, either through hidden mutators
available only to a circular list constructor, or else via promises.

Rejected.  The hidden mutators might become available again through
record introspection, though I hope a successor to SRFI 99 would prevent
introspection of sealed types.  Respecting promises in icdr fields
would again slow down operations that should be fast and efficient.
In addition, only a few SRFI 1 procedures accept circular lists anyway.
A preliminary proposal for bidirectional immutable cycles is currently
available at <http://trac.sacrideo.us/wg/wiki/CyclesMedernach>.

10. Consider an -i or -im suffix analogous to the -ci suffix for string
procedures.

Rejected.  These are among the most commonly used procedures in Scheme,
so it pays to keep them as short as possible.  I think 'icar' and 'icdr'
are more readable than 'cari' and 'cdri'.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
In might the Feanorians / that swore the unforgotten oath
brought war into Arvernien / with burning and with broken troth.
and Elwing from her fastness dim / then cast her in the waters wide,
but like a mew was swiftly borne, / uplifted o'er the roaring tide.
        --the Earendillinwe