Re: hash-consing bignums and eq==eql

[Pip Cet <pipcet@gmail.com>]

On Tue, Aug 28, 2018 at 2:08 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> BTW, hash-consing bignums would have the following advantages:
> - EQ is equivalent to EQL for all integers.

I think that's the one to focus on, instead of splitting the vote
between the hash-consers and the slow-EQers. Most users, even Lisp
programmers, won't care how it's done under the hood, but the
distinction between eq and eql for integers leads to subtle bugs that
are best excluded by design, IMHO.

> Admittedly, if we used a dedicated tag for bignums, eql could turn into
>
>     BIGNUM_OR_FLOAT_P (x) ? slow_eql (x, y) : (x == y);
>
> where BIGNUM_OR_FLOAT_P can be just as efficient as FLOATP, so it
> would be cheap enough (IMO) to make `eq` an alias for `eql`.

I rather think it hinges on the question of whether eq = eql should
hold for floats. As you point out, bignums are already much faster
than they used to be, and your theory and my benchmark established an
upper bound for the price of hash-consing that is acceptable on 64-bit
machines.

However, I'd like to point out that if floating-point infinities are
used along with integers, things could get confusing again; I still
have a slight preference for slow EQ compared to hash-consing only
bignums: I think hash-consing floats is problematic unless we have
float immediates (which would include infinities).

Okay, that's complicated. Five options, in my order of preference:

1. Slow EQ
2. float immediates, hash-cons the remaining floats, hash-cons bignums
3. hash-cons bignums, leave floats alone
4. hash-cons bignums and all floats
5. the status quo