XEmacs and APEL

[Shuhei KOBAYASHI]

apel-en に反応しようと思っていて途中まで英語で考えてしまったのですが.

Yamaoka-san, I think you are misunderstanding the problem.

Compile-time evaluation and function inlining are different.  AFAIK,
we APEL developers have a rough consensus on the former, but not on
the latter.  The former is an optimization of APEL itself, while the
latter is that of APEL-based softwares.  I believe that whether to
optimize (in exchange for portability of compiled-code) is up to the
authors of the software, therefore the problem in this case is a bug
of APEL.


Katsumi Yamaoka <yamaoka ＠ jpl.org> writes:
> 1. XEmacs with Mule で byte-compile されているので、XEmacs
>    without Mule で使われた場合に齟齬を生じる。

これは compile-time evaluation の使い方がまずいのが主な原因です.
XEmacs の with Mule と without Mule の判定を compile-time に行なっては
いけません. と, 少し前に APEL のどこかに書いておいたはずです. ちなみに
環境の判定(Meadow かどうかなど)も compile-time に行なってはいけません.


> 2. 古い std11.el と std11-parse.el が含まれていて、現在は FLIM
>    に移設かつ一本化された std11.el と互換性が無い。

これは XEmacs Package の tm が必要としているのかな?
そうであればそちらに移すのが良いでしょうね.


> またつい最近では、mcs-xm.elc において defsubst で定義されている
> 関数 encode-mime-charset-string が、XEmacs without Mule で byte-
> compile した liece などの他のプログラムに埋め込まれてしまうため
> に害を及ぼす問題の対策が行なわれました。

この問題は function inlining が主な原因です. たとえ load-time に定義を
変えるようにしても defsubst している限りは問題が起こります.


>   将来の XEmacs には三つの選択肢があるのではないだろうか:
> 
>   1. APEL をそれぞれの版の XEmacs に含める。
> 
>   2. APEL を XEmacs パッケージから外す。APEL が必要なユーザは、
>      自分でインストールしなければならない。
> 
>   3. 可搬性を持たせるために、性能を犠牲にしてすべての APEL のモ
>      ジュールを書き直す。

1. は既に否定されていて, 2. も APEL に依存する XEmacs Packages がいく
つもあるので非現実的なので, 3. でしょうね. 性能がそれほど犠牲になるか
は私も疑問に思いますけどね;-p

ただ, compile-time check を load-time check に書き換えるのが難しい場合
もあります.

    (defun example ()
      (static-if foo A B)
      (static-if bar C D)
      (static-if baz E F))

を load-time check に書き直すと 8 通りの関数定義を用意することになり,
このようなものを書き換えるのは現実的ではないと思います.

また, APEL には実際にファイルを作成して入出力関数の挙動を調べている部分
がありますが, これも load-time check にするのは問題があるでしょう.

ということで,

  3'. XEmacs Packages 用の APEL を別に作成する.
      個々の compile-time check は個別対応.

という方針でやってみるのが APEL を全体的に書き直すよりはましかな, と.

-- 
Shuhei KOBAYASHI