all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Pip Cet <pipcet@gmail.com>
To: "Mattias Engdegård" <mattiase@acm.org>
Cc: 38708@debbugs.gnu.org
Subject: bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode
Date: Sat, 28 Dec 2019 16:36:54 +0000	[thread overview]
Message-ID: <CAOqdjBdY1KTA=6JZyrH9VvWr7pTv2KGwtFgvnKJYSdNMpF4roA@mail.gmail.com> (raw)
In-Reply-To: <096F68FE-0CB3-45CD-AB14-89BB5447484C@acm.org>

On Sat, Dec 28, 2019 at 3:49 PM Mattias Engdegård <mattiase@acm.org> wrote:
> 27 dec. 2019 kl. 18.07 skrev Pip Cet <pipcet@gmail.com>:
> > I don't have a strong opinion about this (well, I do, actually: 'eq
> > and 'eql should be equal), but my impression from the last time this
> > was discussed is that the problems this causes (different code
> > behavior for byte-compiled code versus evaluated code) outweighed the
> > benefits (very tiny code size reduction).
>
> Thank you for inspecting my change! And sorry, I didn't know this had been debated before. Is there a record of that discussion anywhere?

It was part of the rather extensive eq-vs-eql debate, I'm afraid.

I'll try to be clear about this: I think anything but making eq and
eql synonymous is likely to cause problems that drive programmers away
from Elisp. But there are axioms that programmers can rely on that are
stronger than what eq actually promises. For example, two objects
might be thought either to be eq to each other or not, but code such
as this:

(defun my-not-eq (x y) (not (eq x y)))

(defun always-t ()
  (or (eq 18446744073709551616 18446744073709551616)
      (my-not-eq 18446744073709551616 18446744073709551616)))

(byte-compile 'always-t)
(always-t)

will yield unexpected results.

> > Most importantly, I think that we should be able to be define
> >
> > (defun f () (eq 18446744073709551616 18446744073709551616))
> >
> > That function should always return t on sane systems that have eq =
> > eql, and always return nil on systems that have <64 bits in a fixnum
> > and the old-style eq.
>
> I'm not sure I understand. Surely such a criterion imposes a rather low limit on permissible optimisations?

Yes, it does. I think any change in the behavior of eq, except for
making it equal to eql, is likely to break code that's out there
somewhere (and that doesn't mean we hear about it; more likely, people
end up abandoning Elisp and using JavaScript instead). So the second
best option is to keep the current (pre-patch) behavior in which (eq
1.0 1.0) is reliably nil, IMHO.

Technically, I think code such as

(cond ((eq a b) 1) ((not (eq a b)) 2) (t 3))

is allowed to return 3. We should attempt not to make changes that
make this more likely, though.

(Again, is this really what we want? If you can't modify an eq-based
hash table reliably, because keys might have become eq (and thus
overwrite each other) that weren't eq when you checked the hash table,
what can you use such hash tables for?)

> For example, shouldn't
>
> (eq (ash 1 x) (ash 1 x))
>
> be allowed to be optimised to t (after CSE, say), even if x can be 64, despite the fact that interpreted or low-optimised compiled code would yield nil in that case?
>
> Perhaps the change should really be done on the emacs-27 branch, to avoid changing bignum behaviour, but that is just a slightly weaker version of the same restriction. Unless we decide to turn eq into a synonym for eql, eq is a one-sided conservative approximation of eql for bignums and flonums.

You're right, that is eq's contract. But people do misuse it, and one
of the things they wouldn't expect is that optimization results in
things becoming non-eq that were eq before optimization; I think the
other direction is much less problematic.

> > Anyway, I still think the right course of action here is to fix (or
> > deprecate) eq rather than changing minor details of the byte compiler
> > in incompatible ways. However, if we decide the gain is significant
> > for floating point numbers, let's restrict this to floating point
> > numbers and leave bignums alone?
>
> What would anyone gain from such a restriction? And the change is minor because it's a small thing to do; what I thought looked like an obvious oversight, or one that made more sense back when Elisp didn't have bignums.

Well, Elisp has had floats for a while, and bignum constants appear to
be nonexistent, so far.





  reply	other threads:[~2019-12-28 16:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-22 16:42 bug#38708: [PATCH] Deduplicate flonum and bignum constants in bytecode Mattias Engdegård
2019-12-27 14:24 ` Mattias Engdegård
2019-12-27 17:07 ` Pip Cet
2019-12-28 15:49   ` Mattias Engdegård
2019-12-28 16:36     ` Pip Cet [this message]
2019-12-28 18:50       ` Mattias Engdegård
2019-12-28 19:07         ` Eli Zaretskii
2019-12-29 17:29         ` Pip Cet
2019-12-29 22:30           ` Mattias Engdegård
2019-12-30 15:46             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOqdjBdY1KTA=6JZyrH9VvWr7pTv2KGwtFgvnKJYSdNMpF4roA@mail.gmail.com' \
    --to=pipcet@gmail.com \
    --cc=38708@debbugs.gnu.org \
    --cc=mattiase@acm.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.