Re: SRFI 43 vs. R7RS-small Taylor R Campbell 28 Oct 2015 15:49 UTC
Date: Wed, 28 Oct 2015 09:26:00 -0400 From: John Cowan <email@example.com> 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. I doubt whether SRFI 43 matters to anyone. One is better served all around by foof-loop than by SRFI 43. 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. Preferred. This is a problem that one may have to deal with in any sufficiently large and diverse code base. 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. Reasonable. 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. Reasonable. 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. Sounds awful.