「Lightweight Language Day and Night 2005 開催」記事へのコメント

私案：継続ベースもどきをお手軽に実現できないか

[G7 (3009)]

ほんとに報告コメントとか止まってますね(T_T)
一般的な話は、スラド諸兄、もといBLOG諸兄に(T_T)任せるとして、
遅れ馳せながら俺は、
俺個人が思ったことについて少々。

俺が興味深かったのは、WebFramework対決での、
Kahuaの「継続ベースのWebアプリ」のあたりですね。

まず質問者に継続どころか入れ子関数すら理解してない人が居たのが
(わるいんだけど)面白おかしかったってところ。
おーい、世の中、ローカル変数とグローバル変数の2段階しかない言語ばっかりじゃないんだよー。
会場では「なんでも継続 [dreamhost.com]読ませろよ」って声が飛んでたけど、
3分で読んで3分で理解できるかってーと怪しいし、
そもそも関数の概念自体がC/Javaレベル(^^;に固定されてた人だったように見受けるんで、
まずをそっちを理解するのが先かと。
＃でも周囲の応答もイマイチだったなあ。「ぜんぜん違うプログラミング形態だ」ということがきちんと伝わっただろうか？

いや、その人自体はどうでもいいんだけど(それに知識は単に学習すれば済むことなんだけど)、
一般的にも、これくらいに継続どころか入れ子関数すら
「知らない」し、それゆえに「活用できない」人が
多いんじゃないか、という気がするんです。

そしてそれはひいては、
KahuaみたいじゃないFWども (Strutsとかは言うに及ばず、評判の高いRubyOnRailsとかですら該当する)
が惰眠をむさぼってるという現状を、生んでいるんじゃないかと。

だって考えてもみようよ。
ユーザイベント(入力)をTOPレベルの基点としてプログラムを記述するほうが、
快適に記述できる場合も、もちろんいっぱい有るわけだけど、
逆に、処理の合間にユーザに問い合わせるっていう「処理の流れ」を
そのまま記述したほうが快適に書ける場合も、あるわけじゃん。

(主客の転倒ね。前者は入力の配下に処理がある。後者は処理の配下に入力がある。)

でもStrutsは言うに及ばずRoRですら、そういうのをサポートしてないそうなので。

「してないそうなので」というのは、まさにそういう
Web Linear Programming(*)をサポートしてますか？みたいなことを
質問した人が会場に居たので。
(俺じゃないです。でも正に言いたいことを代弁してくれた感じ。)

        (*)たぶん俺造語です。でも継続ベースのWebアプリを
        Linear Programmingと呼んだ人は、既に居たと思う。
        あたまに「Web」をつけたのは俺が考えた。
        ちなみに世間でLinear Programmingというと、
        なんか線形計算だかなんだかいう全然別の概念を指すらしいんで用心桑原。

で、サポートしてなくても不満が出ないのは、つまり
それの便利さをみんな気づいてないから、ってことなんじゃないかと。
知らないから、なんじゃないかと。

ーー
で。俺が考えたのは、
じゃあ代用手段でサブセットな道具を作ったら、
それはそれなりにご利益が有るんじゃないかな？と思ったんだ。
(というか、思ったのはLLDNより少し前からだけど。)

継続でやれて嬉しいことの1つとして、
「処理の合間にユーザ入力を待つ」という記述がすんなり出来る
って点が有ると思います。
(少なくともLLDN当日に出てきたネタはソレだけでしたよね。)

俺もまた継続を正しく理解できてないんだけど(わら)、
その俺なりに考えた(つまり継続理解してない頭でも判るやり方)のが、
「スレッドで代用しようかな？」です。

HTTPライフサイクル(ってのか：1回のRequestからResponseまでの処理の流れのこと)の中で、
最初の「Requestを解析して仮Viewオブジェクトに収める」のと
最後の「Viewオブジェクトを解析してResponseに収める」のとの
2つだけは
MainThread(というかServletから呼び出されたときのThread)で実行し、
その間の「ユーザ処理：Viewを解釈してModelを更新したりとかする」の部分は、
別途生成したSubThreadで実行することにしたら、
いいんじゃないかと。

で、普段は、
複数Threadじゃないかのように振舞えばいい。
つまりMainはSubを起動したら、Subの終了を待ってから再開すればいい。

いっぽう、上記のように「入力待ち」をしたい場面になったら、
SubThreadを「入力待ち」の場面で眠らせちゃうの。

Mainは正確にいえば(つまり両方のケースをサポートするために)
Subが「死ぬか眠るかどっちか」するまで待てばいいんじゃないかな。
(待ち方は、とりあえずPollingしか思いつかないけど、もっと良い手段があればそれで。)

Subが死ねばMainは単に自分が続きの処理をするだけ。
ViewはSubが既に完成させてるはずだ(^^;から、それを読んでResponseに変換する。

Subが眠ったら、Mainはこれまた自分の続きをするんだけど、
そのとき「Subがまだ存在はしてるよ」ってのを記録しておく。
(というかSubThread自体を変数に入れて保存しとけ)

そして、Subが存続した状態で2度目のRequestが来たら、
Mainは前半の処理(待っていた入力項目のViewへの格納も、ここで行われる)をしてから、
Subを「再開」させる。
するとSubは「気づいてみたら、然るべきObjectに然るべき情報が入っている」
という状態になる…はず。

以下、同じように、Subは自分の処理を終了して死ぬか、
あるいは再び入力待ちに入って眠るか、
どちらかを繰り返すことになる。

これでもって、
とりあえず「GUIアプリでいうところの、MODALダイアログ」
みたいなことが出来るようになるんじゃないかと。

継続ベースだと、既存FWを書き直すのは大変かも知れないし、
FWのユーザであるプログラマも「理解できない」人が多いかも知れない(わら)。
でも上記のように
「単にスレッドですよ」
「出来ることは単にMODALダイアログですよ」
という風に言っちゃえば、まだ理解しやすいんじゃないかなーと
憶測しています。

＃試作FWなら作る気あるのでG7
＃去年の今頃作ってたイベント駆動ベースのWebFW試作品に、
＃上記のスレッドの仕組みを追加すればいける…んじゃないかと。

あと、リソースも比較的食わないんじゃないかな。
継続ベースだと使いふるし(かも知れない)継続がメモリにいっぱい溜っちゃうようだけど、
上記の俺案だと、しょせんサブセットなぶん、 Threadの個数は１セッションあたり、

        MODALしてるダイアログの数(入れ子する場合もありえるんで)＋１(元Thread)

で済むんじゃないかと…