Pkgs built with 21.5 can't be used in 21.4 (or SXEmacs)

@Aidan:

You're CC'd because I'm wondering if there isn't a better way to
implement the bytecode compatibility test.  Ie, maybe we should have a
"Vimplemented_bytecodes" bitvector for this kind of test to make it
clear what's really happening.

Of course, "inquiring minds" are waiting with baited breath for
answers to Steve's questions, too. :-)

Steve Youngs writes:

 > OK, so here's the problem... elisp that has been byte-compiled with
 > XEmacs 21.5 cannot be loaded with XEmacs 21.4, or SXEmacs.

Yup.  In theory, it's been that way since the very beginning, although
it was as late as August 2009 when the door actually got nailed shut.
That's why we insist that official packages be built with 21.4 (or
SXEmacs should do, but I think Norbert does use 21.4).

 > Why?  Because...
 > 
 > XEmacs 21.5: (special-form-p 'throw) => t
 > XEmacs 21.4: (special-form-p 'throw) => nil
 > SXEmacs: (special-form-p 'throw) => nil
 > 
 > It would seem that somebody thought it was a good idea to make Fthrow()
 > take "possibly unevalled" arguments.  I don't understand the reasoning
 > behind that and I'd certainly love to know.

Aidan done it.  I don't know exactly why, either.  The ChangeLog
indicates it's related to Common Lisp compatibility, specifically real
multiple values.  It involved new bytecodes, so if those are used,
21.4 (and presumably SXEmacs) are in big trouble (probably a crash).

 > May I ask, what is the thinking behind this test?  If it is to
 > ensure that only certain versions of (S)XEmacs can load the lib
 > wouldn't it be far easier (and give finer control) to inject
 > something like this [version test].

I don't think so.  Feature tests are preferred for this kind of thing,
especially during development when features may be enabled or not for
different builds, and when several branches are active (and therefore
feature presence does not respect a total order of versions).

 > It just seems really odd (and annoying for me) that XEmacs would
 > rely on the definition of a function as a means of restricting
 > where a elisp can be loaded.

Elisp can be loaded anywhere.  Byte-compiled lisp is loadable only
where the runtime is compatible with the compiler used.

Whether this particular incompatibility was a good decision or not is
something you'll have to debate with Aidan.  I tend to side with Aidan
on the grounds that there's a good workaround for code that should and
does run on both 21.4/SXEmacs and 21.5: compile with 21.4 or SXEmacs.

Note that as far as the multiple values feature goes, Aidan added code
to 21.4 and/or xemacs-base that makes code using multiple values work
on 21.4 and 21.5 without change or checks other than the check for
unknown bytecodes (that's what the check on `throw' really does).