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)
|
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