メッセージ。 - 出版コンパイラは作れるか？

要は、出版界にとっての「最終原稿」というのは、紙というアーキテクチャ、しかもA4とかB5とか四六判とかに最適化されたバイナリデータなんですね。一方で、執筆者、しかも理系の人は、「最終原稿」を「デジタルテキスト」と考えているんだと思います。（ぼくも理系の人間なので、そう考えたくなるほうです）

たぶん、両者における溝の1つは、「コンパイラの存在」を前提としているかどうかだと思います。コンパイラがあれば、ソースコードとなるテキストを編集しておいて、それをコンパイルして紙用バイナリをいくらでも吐き出せるだろうと。そして、最終原稿のデジタルテキスト（ソースコード）も手に入るだろうと。

でもこう、出版界というところでは、それほど抽象度高く、レイヤ分けして作業できていないんです。まず、コンパイラというものが存在しない。なぜか？ ぼくも「デジタルテキスト」が欲しくて、コンパイラを作ろうとしたのですけどねー。でも挫折しました。挫折の理由として1つ挙げられるのは、ソースコード（テキスト）の文法などというものは存在しないし、仮に作ったとしても執筆者にそれを強制できないということです。

「だったら、文法の違いを吸収するコンパイラを作ればいいじゃん。原稿のテキストなんて複雑なセマンティクスを持たないんだし」。そう。そう思って、文法吸収器も作ったんですけどねー。これも次第に使わなくなりました。そもそも、いただく原稿が決定的文法じゃない場合が多くって。しかも、コンパイラのような抽象レイヤをかますと、生成されたファイルのチェックも必要になります。このチェックがまた、ねぇ。自動テストツールを作るにしても、エントロピーが結構大きくて。結局普通にやる（従来のシステムを使う）ほうが効率的だということになりがちでした。うがががが。

……って、つらつら書いてるけど、長いなぁ。この話題って読みたいですかね？ 個人的には、喋り出すと止まらない話題なんですけど。。。とりあえずここまででやめときますｗ。