【伺か】Shiolink/Perlの実装【栞】
-- 2011/12/09 19:00
Perl栞Shiolink/Perl Simpleを先日公開したが、Simpleではないバージョンがもともとの開発目標だった。
すなわちSHIORI応答基礎・包括的なイベント処理・個別のイベント処理とかでそれぞれ階層化してオブジェクト指向プログラミングの作法で記述したPerl栞である。
現時点では一応それっぽい形が一つ完成し、Shiolink/Perl ShioriEngine_Perlなどという名前でモジュールを公開しようかと思っている次第である。ただPODやREADMEを書いてないし、実例イベントがやる気でないのでまだまだだという気はするが。
一方で、「包括的なイベント処理」のレイヤを独自実装ではなく互換実装にしようという無駄っぽい試みを企てたのもある。開発を進めている華和梨互換動作用エンジンShioriEmulate_Kawariがそれで、もともと華和梨辞書の完全な読み込みを目指したところからこれははじまった。
ご存じ華和梨の便利な特徴「${}」「$[]」「$()」「全部名前で管理」など。まずは${}のみブロック改行NGでテキトーに実装していたときに、ブロックを解釈するための方法を考えていったところその他の括弧も全て構造を読み込む方向に行ってしまい、そうすると今度はkisのパースがしてみたくなってくるとこういう訳で。
と、ここで暗礁に乗り上げた。
華和梨の動作の基幹部分'kis'。kisスクリプトをパースするにはとりあえず全エントリの対応情報がないと逝けない。一方それぞれのエントリはそれぞれ個別で再帰的にkisコマンドを解釈する必要がある。
さてここで困るのだ。
それぞれ単一のエントリが自分で自分を構造木に従って再帰的にパースしていくという方式が美しいと思ったのだけれど、そうなるとそれぞれの構造木の要素が現在の全エントリの情報を参照するポインタをもっていなければそれぞれの中でkisパース($())をすることができないということである。
……全エントリの全構造木それぞれの要素に全く同じポインタがいくつもある……。全くこんなに無駄なことはない。
コレの解決策としては当初、
・インスタンスを作らずkisをその時々のエントリ辞書で実行
・再帰はあきらめて改めて順次構造パースする
が思い浮かんだがどうもしっくりしない。
僕の考えの範疇では、1番目はどっちにしろグローバルな変数がいるし、2番目はもう一度構造解析するようなもんだから無駄っぽい……。
そこで考えたのが「レキシカル変数=local」。$dictが効いている領域でエントリを再帰パースすれば、kisはそのエントリを参照することができる……ポインタをそれぞれの要素に入れる必要はなくなるし、ちゃんと再帰な設計であるし、kisはインスタンスの"ようなもの"として存在できる。
しかしレキシカル変数による実装は同時に複数のインスタンスが存在しえないこれはやはりOOP的ではない。グローバル変数による実装と何ら本質は変わりないのだ。
……思案したが、やはり再帰の美しさを捨てきれない。OOPは無理だった。最後の方法で実装することにした。レキシカル変数万歳。
もっといい実装があったらなあ……。
すなわちSHIORI応答基礎・包括的なイベント処理・個別のイベント処理とかでそれぞれ階層化してオブジェクト指向プログラミングの作法で記述したPerl栞である。
現時点では一応それっぽい形が一つ完成し、Shiolink/Perl ShioriEngine_Perlなどという名前でモジュールを公開しようかと思っている次第である。ただPODやREADMEを書いてないし、実例イベントがやる気でないのでまだまだだという気はするが。
一方で、「包括的なイベント処理」のレイヤを独自実装ではなく互換実装にしようという無駄っぽい試みを企てたのもある。開発を進めている華和梨互換動作用エンジンShioriEmulate_Kawariがそれで、もともと華和梨辞書の完全な読み込みを目指したところからこれははじまった。
ご存じ華和梨の便利な特徴「${}」「$[]」「$()」「全部名前で管理」など。まずは${}のみブロック改行NGでテキトーに実装していたときに、ブロックを解釈するための方法を考えていったところその他の括弧も全て構造を読み込む方向に行ってしまい、そうすると今度はkisのパースがしてみたくなってくるとこういう訳で。
と、ここで暗礁に乗り上げた。
華和梨の動作の基幹部分'kis'。kisスクリプトをパースするにはとりあえず全エントリの対応情報がないと逝けない。一方それぞれのエントリはそれぞれ個別で再帰的にkisコマンドを解釈する必要がある。
さてここで困るのだ。
それぞれ単一のエントリが自分で自分を構造木に従って再帰的にパースしていくという方式が美しいと思ったのだけれど、そうなるとそれぞれの構造木の要素が現在の全エントリの情報を参照するポインタをもっていなければそれぞれの中でkisパース($())をすることができないということである。
……全エントリの全構造木それぞれの要素に全く同じポインタがいくつもある……。全くこんなに無駄なことはない。
コレの解決策としては当初、
・インスタンスを作らずkisをその時々のエントリ辞書で実行
・再帰はあきらめて改めて順次構造パースする
が思い浮かんだがどうもしっくりしない。
僕の考えの範疇では、1番目はどっちにしろグローバルな変数がいるし、2番目はもう一度構造解析するようなもんだから無駄っぽい……。
そこで考えたのが「レキシカル変数=local」。$dictが効いている領域でエントリを再帰パースすれば、kisはそのエントリを参照することができる……ポインタをそれぞれの要素に入れる必要はなくなるし、ちゃんと再帰な設計であるし、kisはインスタンスの"ようなもの"として存在できる。
しかしレキシカル変数による実装は同時に複数のインスタンスが存在しえないこれはやはりOOP的ではない。グローバル変数による実装と何ら本質は変わりないのだ。
……思案したが、やはり再帰の美しさを捨てきれない。OOPは無理だった。最後の方法で実装することにした。レキシカル変数万歳。
もっといい実装があったらなあ……。
- 関連記事
-
-
【伺か】Webベースウェアの作り方(伺か Advent Calendar 2014) 2014/12/11
-
【伺か】ブラウザ上ゴースト実行環境「如何か」【on the Web】(伺か Advent Calendar 2014) 2014/12/10
-
【伺か】Shiolink/Perlの実装【栞】 2011/12/09
-
【伺か】ミドルウェアのんびり制作中【華和梨】 2011/09/10
-
【伺か】WineでSSP【Linux】 2011/04/05
-

コメント