[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#38708: eq vs eql in byte-compiled code
From: |
Mattias Engdegård |
Subject: |
Re: Bug#38708: eq vs eql in byte-compiled code |
Date: |
Wed, 1 Jan 2020 13:38:57 +0100 |
31 dec. 2019 kl. 18.38 skrev Paul Eggert <address@hidden>:
> One possible compromise would be to duplicate only bignums in the emacs-27
> branch, while reserving flonum deduplication for the master branch. This would
> help a bit with now-incorrect code that uses eq to compare bignum values,
> while
> not introducing flonum "paradoxes".
The flonum/bignum deduplication patch is only in master at this point. If you
think it emacs-27 would benefit from a version of it that specifically excludes
flonums, this could of course be arranged.
In general, though, my impression is that the likelihood of any trouble in
practice is nil (speaking as the author of the change, of course).
More important is how to present equality semantics to the user, through
documentation, NEWS, and examples. This includes:
- What 'eq' can be used for: what we recommend, and what we guarantee.
- Which equality relation to use and when: eq, eql, equal, =, string-equal, etc.
For example, while we have to guarantee that 'eq' works for fixnums for
compatibility, it may be unwise to give this fact prominence in the
documentation. One of the benefits of bignums is that users no longer have to
worry about fixnum ranges in most cases. The standard rule should be not to use
'eq' for numbers of any kind.
Whether to specifically mention characters as eq-comparable is a matter of
judgement. (Neither CL nor Scheme guarantee that characters can be used with
eq/eq?.) Of course my own code is littered with eq for characters, but do as I
say...
Attached is a proposed documentation patch for emacs-27. While not perfect, it
should at least be an improvement (and fixes at least one error).
> How about going a bit further, and globally deduplicating all flonums and
> bignums that result from low-level text-to-number conversion and module
> imports?
> That conversion is slow and/or rare already, and if we're lucky deduplication
> wouldn't make things noticeably slower and wouldn't be much work.
Maybe, but wouldn't that slow down reading .elc files (and still not shorten
individual constant vectors)?
0001-Clarify-eq-on-numbers.patch
Description: Binary data
- Re: Bug#38708: eq vs eql in byte-compiled code,
Mattias Engdegård <=