On Wed, Oct 28, 2015 at 9:26 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
> 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.
>
If it is called SRFI-43, it MUST follow the standard, and its bindings
should shadow those of the environment into which it is imported; too
bad if that conflicts with other useful functionality.

> 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.
>
I believe 3 is better than 2, but anything that doesn't *exactly*
match SRFI-43 *must not* under any circumstance be called "srfi-43".
However, it can be called "srfi-43-modified-for-r7rs", or something
else that evokes srfi-43. Probably, someone should issue a new srfi
that does just that.

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

> 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.
>
Sorry for a late reply.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Moderation in temper is always a virtue;
but moderation in principle is always a vice. — Thomas Paine