Re: Bytecode interoperability: the good and bad

[Stefan Monnier <monnier@iro.umontreal.ca>]

> In other kinds of bytecode such as the one for C Python, a bytecode version
> number is stored in the bytecode file.  When there is a change to the
> bytecode, that number is changed.

So far, the only changes that have been made to the byte-code language
is to add new (previously unused) byte codes.  So from this perspective
we have always maintained backward compatibility (you can run a .elc
compiled with an older Emacs).

We do not aim to maintain forward compatibility (so whether a .elc file
compiled with a more recent Emacs will work is not guaranteed), although
it sometimes does work.  When encountering an unknown byte-code, Emacs
signals an error, so it shouldn't cause a crash nor "something unintended".

Compatibility problems with .elc files compiled with other Emacs
versions can also come from macros, and those tend to be more frequent
than the problems introduced by changes to the byte-code.  So detecting
a different byte-code version is not sufficient to catch the most common
problems anyway.

FWIW, I think Emacs deserves a new Elisp compilation system (either
a new kind of bytecode (maybe using something like vmgen), or a JIT or
something): the bytecode we use is basically identical to the one we had
20 years ago, yet the tradeoffs have changed substantially in the
mean time.


        Stefan