Kuwataさんが、「CatyScriptのレイフィケーションができるようになった。」と書いてますが、これだけじゃなんだかワカリマセンよね。
最近、Catyのなかに“かなり正確なスノーグローブ”を作ろうとしているのです。少し前に「スノーグローブ現象 再び」という記事を書いたのも、そんな背景です。「かなり正確なスノーグローブ」とは、Catyシステムに関する情報を、Catyのデータ領域に埋め込む機能です。Catyのデータ領域はXJSON(JSONをわずかに拡張したフォーマット）データの集合なので、スノーグローブの実現は「メタ情報 → XJSONデータ」という写像を作ることになります。このような写像をレイフィケーションと呼びます。レイフィケーションの対象となるメタオブジェクトには、型、コマンド、スクリプトコード（コマンドの実際の定義）、リソースクラス、Web状態（REST用語でのアプリケーション状態≒画面）、モジュールなどがあります。
小人さん達の仕事
「スノーグローブ現象 再び」で、再帰構造、メタ巡回構造の類＜たぐい＞であるスノーグローブ的現象を偏愛していると書きました。ですから、趣味嗜好に基づく拘りがあるのは事実なのですが、実用性がないかというと、そんな事はありません。実務上も極めて重要な機能です。特に、僕が大ッキライなタイプの作業 -- コンピュータにやらせるにはチョットだけ知的過ぎるが、人間には退屈でつまらなくて辛い作業 -- これを減らすにはレイフィケーションがどうしても必要なのです。
「2010年末に再び考える、Catyスキーマとユーザーインターフェース」の最後のほうに、次のように書いています（強調もママ）。
さして知的でもない作業を人手でやるのはウンザリ。型の定義を目視で見て、対応するHTMLフォームを書き下すなんて作業はウンザリの典型ですね。
[...snip...]
型や手続きや関係やらが、データになっていれば、通常は人間がやるような概念的（に見える）操作もコンピュータに任せることができます。つまりは、現実の世界や概念の世界の事物をコンピュータのなかに押し込めればいいのです。コンピュータのなかの世界には、当のコンピュータ（プログラム）自身も入れ子に埋め込まれることになります。これがメタ循環構造です。
メタ循環構造を実現すれば、コンピュータがやれる作業が増えて、僕らは楽できます。
ウンザリする仕事をコンピュータにやらせて楽をしたいのです。ウンザリする仕事とは：
- Webサイト／Webアプリケーションのモックアップの作成
- 静的リソースがちゃんと置いてあるか、動的リソースに対応するプログラムは動くか、のチェック
- ハイパーリンクが確実に繋がっているか（リンク切れがないか）のチェック
- ヘルプ／リファレンスのドキュメンテーションを書く
- 仕様書から図を描く（すぐ下にあるような）
- リグレッションテストや長時間テスト用のテストデータやテストスクリプトを作る
Catyでは、これらの作業の素材となる情報はすべてスキーマモジュールに含まれます。プログラムが素材となる情報にアクセスできるなら、少しだけ知的だが所詮は単純労働である仕事はプログラムにも出来ます。問題は、ソースコードや仕様書などの情報がプログラムからは見えてないことです。
通常は、ソースコードや仕様書に含まれる情報は、プログラムが扱えるデータ領域にはなく、いわば天上界の存在です。その天上界の存在物をデータ領域に落としてやることがレイフィケーションです。別な言い方をすると、我々人間が扱い／我々人間しか扱えないと思われていた情報を、スノーグローブ内にも注入してあげるのです。すると、スノーグローブ内にいる小人さん達が僕らの代わりに仕事をしてくれるんですよね。
そして、僕達の仕事
レイフィケーションで得られたデータは小人さん達だけじゃなくて、僕達にも役に立ちます。例えば新しい実行エンジン（仮想マシン）が出来たとして、そのエンジン向けのコンパイラはCatyScriptでも書けるようになります。CatyScriptでコンパイラ？ -- 当初のCatyScriptは、30行書くとヘロヘロになる*1というマゾヒスト向けスクリプト言語（esolang）だったのですが、最近は、文芸的プログラミング方式で千行くらい書くのは割と楽勝になっています。コンパイラのプロトタイプくらい書けますよ。
スクリプトコードのレイフィケーションイメージは、だいたいAST（Abstract Syntax Tree）に対応します。このASTデータの操作は構文的な変換（syntactic(al) transform）になります。Kuwataさんが書いているように、デバッグ用のインストラクションを挿入することもできますし、マクロ定義にも応用できます。
マクロが欲しくなる状況はけっこう多いのです。苦し紛れにテキスト置換を使ったりもするのですが、テキスト置換方式のマクロはほんとにロクデモナイしろもので、構文構造をちゃんと認識して変換をしないとダメです。マクロの実現はけっこう難しい課題で、まだ色々と準備が必要ですが、スクリプトコードのレイフィケーションはその第一歩になります。
*1:これはホントです。僕は「10行くらいが限界かな」と言っていて、Kuwataさんが30行も書いたときには「すごい大作だな」と言っていたくらいです。
