[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#31688: 26.1.50; Byte compiler confuses two string variables
From: |
Phil Sainty |
Subject: |
bug#31688: 26.1.50; Byte compiler confuses two string variables |
Date: |
Mon, 04 Jun 2018 22:02:27 +1200 |
User-agent: |
Orcon Webmail |
On 2018-06-04 01:05, Andreas Schwab wrote:
On Jun 04 2018, Phil Sainty <psainty@orcon.net.nz> wrote:
I generally dislike it when byte-compiled and interpreted code
give different results.
This really has nothing to do with byte-compilation. Whether
literals are shared or not should not be relied upon. You always
have to be careful when modifying values in-place.
I don't disagree that one ought to take care when modifying values
in-place, but my general concern is purely that the byte-compiler is
producing code which does not behave the same as the uncompiled code.
(i.e. I think my issue is specifically to do with byte-compilation,
and I would consider such discrepancies to be a problem irrespective
of the sort of code which was affected.)
Surely consistent behaviour between compiled and uncompiled code is
not only desirable, but a primary goal?
I realise (albeit vaguely) that the byte code and its interpreter are
rather different to the uncompiled versions, so I suppose this may not
be the only situation where a discrepancy results; but I think that
known cases ought be identified and documented (and I think that
eliminating such differences may be a valuable improvement).
The "(elisp)Byte Compilation" info node could certainly do with a
child node detailing the ways in which byte-compiled code behaves
differently from uncompiled code, so that elisp authors can gain an
understanding of all these nuances from a single section of the
manual.
Whether literals are shared or not should not be relied upon.
Why?
I mean, in this case we already know the answer, but why shouldn't the
behaviour be consistent and dependable between the two variants?
Again, it bothers me to think that someone could observe a bug when
running byte-compiled code, and try to debug it but, through the
process of instrumenting functions for debugging, unwittingly change
the behaviour of the code such that the bug no longer occurs.
-Phil
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Gemini Lasswell, 2018/06/02
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Noam Postavsky, 2018/06/02
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Gemini Lasswell, 2018/06/02
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Drew Adams, 2018/06/02
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Phil Sainty, 2018/06/02
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Noam Postavsky, 2018/06/02
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Phil Sainty, 2018/06/03
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Andreas Schwab, 2018/06/03
- bug#31688: 26.1.50; Byte compiler confuses two string variables,
Phil Sainty <=
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Eli Zaretskii, 2018/06/04
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Andreas Schwab, 2018/06/04
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Eli Zaretskii, 2018/06/08
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Michael Heerdegen, 2018/06/02
- bug#31688: 26.1.50; Byte compiler confuses two string variables, Drew Adams, 2018/06/02