Am Do., 10. Dez. 2020 um 17:40 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> On Thu, Dec 10, 2020 at 4:00 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>>
>> Indeed, `mapping-search` is affected because I never thought about
>> using a non-equivalent `new-key` when I wrote that code. Of course, it
>> can be fixed by special-casing that case, but it would be better to
>> add an erratum to SRFI 146 saying that `new-key` has to be equivalent
>> to `key` in the sense of the comparator. This is what has always been
>> the intended use anyway.
>
>
> That's an API change, but if it was always what was intended, I suppose it can be added as an erratum.  But what was the point of providing that argument if it wasn't to allow changing the key?

(1) As the sample implementation has never worked with the
unintendedly overly general current spec, I have a good feeling about
this erratum. Apparently, no one has yet exploited what I would like
to restrict.

(2) The key is allowed to be changed. However, the change must be
compatible with the equivalence relation defined by the comparator
used for the mapping. This is needed, for example, to implement
`mapping-set` (as opposed to `mapping-adjoin`).

Marc