Alex Shinn scripsit:

> I don't recall, and it wasn't discussed explicitly, but I'm not sure
> we missed it.

Yes, I intended what we eventually got, but I missed that it was
discrepant with SRFI 43.

> I'm fine with the conflict, unless you want this to be an "official"
> R7RS-large library, e.g. as (scheme vector),

That is indeed what I intend to propose.

> in which case I prefer #5: fork SRFI 43 removing all uses of the
> index, and rename the existing SRFI 43 vector-fold to something like
> vector-tabulate.  Otherwise #4, fork maximally, renaming in favor of
> consistency with SRFI 1 and R7RS.

I think by #4 you mean #3.  #4 means to invent a mechanism whereby
the problematic procedures (the correct list is -fold, -fold-right,
-map, -map!, -for-each, -count) can figure out whether their procedure
arguments "want" an index; it's only hypothetical.  #3 involves two
sets of procedures, the plain ones that don't pass indexes and the
"/index" ones that do.

Your #5 is interesting, and certainly I'll consider it.  Other opinions?

(All that said, the inability, given a Scheme procedure, to determine
*anything* about its calling protocol is a definite weakness/restriction in
Scheme that ought to be removed, though I have no idea how at the moment.
Arity inspection solves part of the problem, but wouldn't be sufficient here.
Having to use a fixed, static protocol when calling an unknown procedure
is what leads to problems like this.)

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
But you, Wormtongue, you have done what you could for your true master.  Some
reward you have earned at least.  Yet Saruman is apt to overlook his bargains.
I should advise you to go quickly and remind him, lest he forget your faithful
service.  --Gandalf