John Cowan <xxxxxx@mercury.ccil.org> schrieb am 2015-10-28 09:26:
> 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 would prefer 3 (or 4 if such a mechanism looks Schemish).
IMHO, SRFI-43 is not as popular as it should be (compared to SRFI-1),
One (small) reason might be the forced use of indices in some functions,
which might suprise the list-oriented programmer.

Sven