Email list hosting service & mailing list manager


Analyzing the alternatives for SRFI 133 John Cowan 13 Dec 2015 03:57 UTC

To recap, the five proposals are:

1) Do nothing, leave SRFI 43 alone.

2) Replace SRFI 43 -map and -for-each with -map/index and -for-each/index
   to move them out of the way of R7RS-small.

3) Replace SRFI 43 -map, -map!, -for-each, -fold, -fold-right with /index
   names, and add -map!, -fold, -fold-right in non-index form.

4) Have the procedures figure out whether their functional arguments need
   an index or not.

5) Replace SRFI 43 -map, -map!, -for-each, -fold, -fold-right with unindexed
   implementations and keep SRFI 43 -fold as -fold/index (or another name).

I reject 1 on aesthetic grounds.  I reject 4 because nobody knows how
to do it (and nobody voted for it anyway).

I reject 5, though I like it, because vector-fold does not subsume the
others, unlike the case of (list) fold.  You cannot directly implement
vector-map using vector-fold, incrementally producing another vector,
unless you are going to create longer and longer vectors as you go and
then copy their contents, which scales badly.  You need to either fold
the source vector into a list and then do a list->vector, or else create
the target vector in advance and then use vector-for-each to mutate its
elements into the mapped values.

So in order to achieve what 5 intends, you need 3.  That makes 3 the
dominant choice, and mine as well.  I will rewrite SRFI 43 into SRFI 133,
doubling up on the five procedures.  I will also add the procedures from
the current version  of VectorsCowan.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
                if if = then then then = else else else = if;