On 2021-06-10 08:25 +0200, Marc Nieper-Wißkirchen wrote:
> I have given it a bit more thought, and I have two more arguments in favor
> of fxmapping vs int-mapping:
>
> (1) The current option that the keys of SRFI 224 mappings can possibly lie
> outside the fixnum range, is not really helpful but actually
> disadvantageous. Indeed, this has a long-distance effect on third-party
> libraries building on SRFI 224.
>
> [snip]
>
> (2) R6RS/R7RS-large have "+" and "fx+", but they don't have "int+". The
> reasons that speak against "int+" (denoting an addition operation that
> takes two exact integers and which is guaranteed to work when the integers
> are fixnums and which may have an implementation-optional extended range)
> speak likewise against int-mapping (vs. fxmapping).

This is starting to make sense to me.  Reading through SRFI 217 again,
I also note that it explicitly defines "isets" as collections of
fixnums (though I don't recall this issue coming up in discussion of
that SRFI), so 217 should really have used the name "fxset".

The current sample implementation is written entirely with fixnum
arithmetic, but I would like to benchmark it with generic arithmetic
and bignum keys at some point.  I wonder if there's a need to provide
special coverage for bignum-keyed maps, or if SRFI 146 mappings would
be reasonably performant?  If so, then there's no reason for SRFI 224
to handle anything beyond fixnums.

I'd like to think about it a little more, but I'm thinking that
"fxmappings" and restriction to fixnums is the best choice for
224.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"In conversations with Web performance advocates, I sometimes
feel like a hippie talking to SUV owners about fuel economy."
--Maciej Ceglowski