Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> writes:

> Am Di., 20. Juli 2021 um 22:50 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>> (2) Alists are still restricted to the `equal?' key comparator, which is
>>> too restrictive for general code.  One can try to remedy this by adding
>>> just another dynamically scoped parameter, say,
>>> `current-alist-equality-predicate' but this makes reasoning even harder and
>>> can cause a further slow-down. Moreover, it will become inconvenient as
>>> soon as code has to deal with two different types of alists in
>>> parallel.er by light years.
>>>
>>
>> We really need a way to attach a comparator to an alist, but I don't see
>> how, unless by consing it onto the alist.
>>
> Then it is no alist anymore, at least not an alist that is accepted and
> returned by a lot of existing procedures.
>
> In any case, the problem is that the representation of an object of some
> data type, in general, does not contain enough information to reconstruct
> the data type. Given 0, do I mean the integer 0, the real zero, or the zero
> in a 13-dimensional Euclidean vector space?

The typical approach as I know it is to have the comparator as parameter
for the procedures.

For example

(dict-ref* dict key comparator)

(though this would also meat: (dict-set*! dictionary comparator key value ...)

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken