I added vector-map-with-index and vector-for-each-with-index as Gauche built-ins to
resolve the conflict (a programmer can of course import srfi-43 with renaming those
two, but it's conceptually simpler to remember "srfi-43's vector-map is 
Gauche's vector-map-with-index".)

If we have a chance to revise it, I'm for the option #2---make a new srfi that supersedes srfi-43
with minimal renaming.  New code will be benefited by clean and consistent naming, and 
it'll be trivial to support legacy code that uses srfi-43 explicitly.


On Wed, Oct 28, 2015 at 3: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.

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