SRFI 43 vs. R7RS-small John Cowan (28 Oct 2015 13:26 UTC)
Re: SRFI 43 vs. R7RS-small Sven Hartrumpf (28 Oct 2015 13:43 UTC)
Re: SRFI 43 vs. R7RS-small John Cowan (28 Oct 2015 14:20 UTC)
Re: SRFI 43 vs. R7RS-small Shiro Kawai (28 Oct 2015 14:57 UTC)
Re: SRFI 43 vs. R7RS-small John Cowan (28 Oct 2015 16:13 UTC)
Re: SRFI 43 vs. R7RS-small Shiro Kawai (29 Oct 2015 01:36 UTC)
Re: SRFI 43 vs. R7RS-small Taylor R Campbell (28 Oct 2015 15:49 UTC)
Re: SRFI 43 vs. R7RS-small John Cowan (28 Oct 2015 16:16 UTC)
Re: SRFI 43 vs. R7RS-small Taylor R Campbell (28 Oct 2015 16:50 UTC)
Re: [scheme-reports-wg2] SRFI 43 vs. R7RS-small Arthur A. Gleckler (28 Oct 2015 21:25 UTC)
Re: [scheme-reports-wg2] SRFI 43 vs. R7RS-small Alex Shinn (02 Nov 2015 06:16 UTC)
Re: [scheme-reports-wg2] SRFI 43 vs. R7RS-small John Cowan (02 Nov 2015 13:56 UTC)
Re: [scheme-reports-wg2] SRFI 43 vs. R7RS-small Shiro Kawai (02 Nov 2015 14:17 UTC)
Re: [scheme-reports-wg2] SRFI 43 vs. R7RS-small Alex Shinn (02 Nov 2015 15:18 UTC)
Re: SRFI 43 vs. R7RS-small Sudarshan S Chawathe (30 Oct 2015 21:10 UTC)
Re: SRFI 43 vs. R7RS-small John Cowan (31 Oct 2015 15:44 UTC)
Re: [scheme-reports-wg2] SRFI 43 vs. R7RS-small Faré (02 Nov 2015 23:08 UTC)
Re: [scheme-reports-wg2] SRFI 43 vs. R7RS-small John Cowan (04 Nov 2015 01:59 UTC)
Re: [scheme-reports-wg2] SRFI 43 vs. R7RS-small Faré (04 Nov 2015 05:53 UTC)

SRFI 43 vs. R7RS-small John Cowan 28 Oct 2015 13:26 UTC

I'd like to take a straw poll on how best to resolve the conflict between
R7RS-small and SRFI 43, the existing vector library that I intend to
propose as part of R7RS-large.  The conflict happens with the functions
`vector-map` and `vector-for-each`.  These have the same signature in
both libraries, but invoke their procedure argument in different and
incompatible ways.

Specifically, the R7RS-small versions are exactly analogous to the R5RS
`map` and `for-each` functions: the procedure is invoked on the current
element(s) of the vector(s).  In SRFI 43, however, the vector index is
passed as a first argument, so that the procedure must accept one more
argument than the number of vectors being processed.  Because Scheme
has no way to discover the kinds of arguments a procedure expects,
this conflict is not portably resolvable.

Here are some possible resolutions:

1) Live with the problem.  This means that importing SRFI 43 into
an environment that already contains (scheme base) will cause import
conflicts that must be resolved by excluding or renaming.

2) Fork SRFI-43 minimally.  Rename the procedures to `vector-map/index`
and `vector-for-each/index` or the like (something better, preferably).
This resolves the conflict, but is fairly unmotivated in SRFI 43 terms.

3) Fork SRFI-43, doubling up on all procedures with procedure
arguments.  This would mean introducing two forms of the seven such
procedures, `vector-fold`, `vector-fold-right`, `vector-reduce`,
`vector-reduce-right`, `vector-map`, `vector-map!`, and `vector-for-each`:
one that accepts an index (and has a name ending in `/index`) and another
that does not (re-exporting the names `vector-map` and `vector-for-each`
in an R7RS context).  This is a full solution, but adds more names and
complexities.

4) Introduce some new mechanism into Scheme to figure out whether the
procedure being passed as an argument wants an index or not.  Simple arity
inspection does not suffice, as the procedure may be written to handle
an arbitrary number of arguments.

I'm sending this to the SRFI-43 and WG2 mailing lists.  Interested parties
are invited to indicate their preferences, or make comments, or both.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
What asininity could I have uttered that they applaud me thus?
        --Phocion, Greek orator