Email list hosting service & mailing list manager

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)

Re: [scheme-reports-wg2] SRFI 43 vs. R7RS-small Faré 02 Nov 2015 23:00 UTC

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