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

>> 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