Yuk.

There's a reason why I implemented slices in MIT/GNU Scheme and changed all the mappers to take multiple strings as arguments -- then there's a good symmetry with lists and vectors.

Oh well.

On the other hand, I find it strange that this history is so constraining.  I'm busy implementing away and I'm just ignoring the conflicts with existing MIT/GNU Scheme implementations, since this is all local to the (srfi 140) library.

Thanks for the response.

On 2019-11-18 20:38, John Cowan wrote:

The string-count procedure is considered a search rather than a map, and the argument order has been the same since SRFI 13.  I don't think there's any chance of changing it now in any SRFI.

On Mon, Nov 18, 2019 at 10:22 PM Chris Hanson <xxxxxx@chris-hanson.org> wrote:

I notice that string-count is different from other string mapping
procedures in that the arguments are in a different order.

All of the other mappers are PROC STRING [START [END]] while
string-count is
STRING PROC [START [END]].

Is this an oversight or intentional?  It seems like a poor choice if
intentional.