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 email@example.com
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