XEmacs and APEL

[Katsumi Yamaoka]

>>>>> In [apel-ja : No.00687]
>>>>>	Shuhei KOBAYASHI <shuhei ＠ aqua.ocn.ne.jp> wrote:

小林さん> 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.

ははは誤解でしたか。でもぼくがあまり整理されていない頭の中で漠然
と思っていたのは、APEL はぼくが誤解していたような姿勢ではマズい
のではないかということでした。しかし、例えば

  *-maybe が compile-time に既に存在しているものに対して何もしな
  いのは良いのだろうか?

のようなぼくの発言に対してまったくご意見がいただけなかったので、
今さら言うまでもなく現状追認が正しい APEL の姿勢なのだろう、はた
また APEL はすでに時代遅れになっていて誰もあえて問題視していない
のだと解釈し、それでもなお、ときどき APEL が原因になっている障害
が取りざたされるたびに、だんだん APEL の存在が鬱陶しくなってきた
のでした。

;; よし、これからは APEL を使わないでプログラムを書こう。APEL が
;; 使われているプログラムは、どさくさに紛れてAPEL を使わないよう
;; に書き換えてしまおう。理由はともかく Emacs の世界には APEL を
;; 排斥しようとする強い意志がみなぎっているので、そういう連中に
;; 実力行使のきっかけを与えてやろう...。

山岡> 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 が必要としているのかな?
小林さん> そうであればそちらに移すのが良いでしょうね.

なるほど、そうですね。tm-std11.el、prefix も tm-std11- にして。

ところで、MIME 機能では Gnus が世界中のパワーを結集して独走して
しまい、VM も追い付いたようですが、SEMI や FLIM が公に汎用 MIME
パッケージになる日は来るのでしょうか?  そしてそれが実現した暁に
は APEL という名前は無くなって、一部の機能だけが SEMI や FLIM に
編入されるのですよね?  もしそうだとすれば XEmacs の APEL package
も tm に入れてしまい (と言うか大昔の形態に戻してしまい)、新しい
汎用 MIME パッケージに対応していない旧式のソフトウェアだけが tm
を使う、というのも合理的ではないかと思います。

;; そう考えていることも、ぼくがなるべく APEL を使わないようにし
;; ている理由です。

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

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

そうですね。そしてぼくの不正確な印象としては、-maybe や broken
を使っている部分も含めて compile-time に決まってしまう内容が多く、
それらが APEL の方針を代表しているように見えたのでした。

山岡> 将来の XEmacs には三つの選択肢があるのではないだろうか:

山岡> 1. APEL をそれぞれの版の XEmacs に含める。

山岡> 2. APEL を XEmacs パッケージから外す。APEL が必要なユーザは、
山岡>    自分でインストールしなければならない。

山岡> 3. 可搬性を持たせるために、性能を犠牲にしてすべての APEL のモ
山岡>    ジュールを書き直す。

小林さん> 1. は既に否定されていて,

これは意図通り。:-p

小林さん> 2. も APEL に依存する XEmacs Packages がいくつもあるので非現
小林さん> 実的なので,

ぼくは実はこれを押したかったのですが、XEmacs の連中の反応は意外
に情けないものでした。良い機会だから目の上のこぶになっている
APEL を排斥するために関連パッケージを直そう、という動きにはなり
そうもありません。

小林さん> 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 通りの関数定義を用意するこ
小林さん> とになり, このようなものを書き換えるのは現実的ではないと思い
小林さん> ます.

そうですね。特にそういうものが Emacs 18 以上のすべてが対象だと非
常に大変なわけですが、Gnus の先端がときどき脱線するように Emacs
21 以上とか XEmacs 21.4 以上を対象にすると話はかなり変わってくる
と思うのです。そういうバージョンの Emacsen だけを使うユーザは大
きな勢力になっており、最近の Emacsen 専用の APEL というのもあっ
ても良い時代になったかもしれません。あるいは、わざわざ APEL とい
う独立したパッケージに集約するまでもない内容しか残らないかもしれ
ません。

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

小林さん> ということで,

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

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

言葉が足りませんでしたが、ぼくが提案した 3. はまさにこの内容でし
た。XEmacs の開発陣にとって APEL の再開発というのは cvs.m17n.org
にあるものが対象ではすでになくなっているだろうと思っていたので。

以上、取り止めの無い文ですみませんでした。ぼくは APEL のコードを
読み書きするのはとても面白いです。過去の多大な功績を忘れていませ
んし、今でも有益なモジュールがいくつもあることは認識していますが、
一面では APEL 排斥論者に肩入れする変な人です。そんなこんなの一部
でも伝わりましたでしょうか? :)
-- 
Katsumi Yamaoka <yamaoka ＠ jpl.org>