bug#31688: 26.1.50; Byte compiler confuses two string variables

[Phil Sainty <psainty@orcon.net.nz>]

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