Re: [PATCH] Implement `equal' for hash tables

Stefan Monnier <[email protected]> writes:

>>> Hash tables are equal if they have equal atoms, weakness, and equality
>>> and hash functions.
>>>
>>> (This also means that equal of structures which contain hash tables is
>>> useful now, too, which is really the reason I implemented this: right
>>> now, hash tables are a sort of poison pill which render any object into
>>> which they are inserted unequal with all others.  No more.)
>>
>> Is it useful in a programming language for hash table objects to be
>> directly comparable like this?  I'm not sure that it is.
>
> I'm sure it's useful at times, tho I agree with Eli that a motivating
> example would be appreciated.  The behavior of `equal` (in terms of which
> objects are compared structurally and which objects use just `eq`) is
> largely arbitrary.  In practice there are situations where we want
> a comparison that goes one way other times another way.
>
> I think the proposed change makes a fair bit of sense as default
> behavior of `equal`, but is an incompatible change, so there's a risk
> we'll break existing packages, and this breakage may reveal itself in
> rather odd ways, so it may prove difficult to track it down and fix it.
>
> `eq`, `eql`, and `equal` only provide a limited amount of choice.
> I think it would be nice to provide a more general solution where an
> additional argument is provided which describes when to use `eq` and
> when not.  The choice could depend on the depth (e.g. for hash-tables
> I often find myself wanting a comparison that behaves structurally for
> a top-level array or list, but not the its elements), or on the type of
> the compared elements.
>
>
> === Stefan

BTW, CL has `equalp` which handles hash tables. Emacs' cl-equalp doesn't.

https://www.lispworks.com/documentation/HyperSpec/Body/f_equalp.htm#:~:text=If%20two%20arrays%20have%20the%20same%20number,are%20ignored%20when%20equalp%20compares%20strings.%20Structures.