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: SRFI 43 vs. R7RS-small John Cowan 28 Oct 2015 16:15 UTC

Taylor R Campbell scripsit:

> I doubt whether SRFI 43 matters to anyone.  One is better served all
> around by foof-loop than by SRFI 43.

One may be, but another may not.  In any case it is not either/or:
the two versions of foof-loop have both been proposed for a later
color edition of R7RS-large along with the other syntactic structures.

> Preferred.  This is a problem that one may have to deal with in any
> sufficiently large and diverse code base.

But it is embarrassing for what purports to be a standard.

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

I wish you would express a preference as between these two.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
        "Not to know The Smiths is not to know K.X.U."  --K.X.U.