portability of *.elc

[Shuhei KOBAYASHI]

>>>>> In <htx1za019xs.fsf ＠ mulelab3.etl.go.jp>,
>>>>> tomo ＠ etl.go.jp (守岡 知彦 /  MORIOKA Tomohiko) wrote:
> invisible は obsolete ということで、使っている code は極力使わないよ
> うに書き直すことにし、また、invisible 自体もいじらないことにしたいん
> ですがいかがでしょうか？
> ;; もしかして使いたい人とかいます？もしそうなら改善する価値があると
> ;; 思いますが。

obsolete でも構いませんが, 使いたい人がいるかもしれないので macro から
関数に変更しておこうと思います.
;; ところで, disable-invisible の alias を設定してもいいんですよね?


> > (b) v19 で bytecode interpreter に多くの opcode が追加された.
[...]
> 回避可能だとしても GNU Emacs 18 と GNU Emacs 19 の *.elc の互換性は
> 不要だと思います。

共有したいという人がいるかもしれません.

> > (d) Emacs 19.29 で keyboard の modifier bit が変更された.
[...]
> 回避可能だとしても、通常、GNU Emacs 19.28 以前と 19.29 以降では
> site-lisp の場所が異なっていますから、*.elc の互換性は不要だと思います。

home の下に個人的に持っている場合は?

> > (e) XEmacs 20 で eq, memq, equal, assq の bytecode が変更された.
[...]
> また、GNU Emacs と XEmacs では、通常、site-lisp の場所が異なっています
> から、*.elc の互換性は不要だと思います。

home の下に個人的に持っている場合は?


上のどの問題もこの,

| (1) APEL 上の application の *.elc の互換性に関する原則.
|     APEL の制限によって APEL を利用する application の *.elc の互換性
|     を制限してはいけない.

APEL の利用者が *.elc の共有を望んでも APEL の制限によってそれが妨げら
れるということが許されるか, という問題になります.

この原則 (1) は

|   * version によって定義の異なるものは compile 時に展開してはいけない.

によって満され, これを実現するのは難しい事ではないです.
;; 可能な限り defun で提供すればいいだけ.


> > また, こうなると, 例えば FLIM や SEMI の場合に *.elc の互換性を
> > 阻害している主要な原因は (a) の code-name だという事になります
> > :-p
> (^_^;;;

これが product info の byte-compile は止めようと主張する根拠です.
もちろん, FLIM や SEMI が *.elc の互換性を維持できなくなれば compile
しても構いませんが, 本来 *.elc の共有が可能なものまで code-name の為に
共有できなくなるのは嫌なので.


> > (c) Emacs 19.29/XEmacs 19.14 で dynamic docstring/function loading
> >     が導入された.
[...]
> dynamic docstring/function loading を望んでいる人のために使用するよう
> にしたという経緯があるので、使える環境では使うようにした方が良いと思い
> ます。

これに関しては dynamic docstring/function loading を使用するなというの
ではなく, これを抑制することで *.elc の互換性を保つことが可能であると
いうことを示しただけです. また, APEL は VERSION_SPECIFIC_LISPDIR に
install されるので, APEL から dynamic docstring/function loading の設定
を取り除こうと主張しているわけでもありません.

-- 
Shuhei KOBAYASHI