明示的なimportの必要性
いつ、どのくらいメッセージが飛び交うかを考える。
1GbpsのEthernetを1500byteのパケットで埋めたとすると、1Gbit / (1500*8)bit = 8万packet/sec。そんなに無いかもしれないけど。
これを単純にTCP/IPからユーザランドにデータを持ってくるために使うと、FASLを作って展開する処理が一秒間に8万回発生することになる。個人的にはこれはそれなりの負荷(10数%〜)になると予想している。
Schemeそのものは単一の名前空間で動作させることが前提なので、何らかのパッケージシステムを追加する必要がある。
skyScheme側の解決
skySchemeは一旦コンパイルして動かすことが前提なので、FASLに相当するフォーマットは静的に固定する(= メッセージフォーマットを自動的に生成)。
R6RS側はシンボルではなくfixnumを使う。これらの定数はR6RS側のimport libraryとして同時に生成する。skySchemeには現在R6RS風のライブラリシステムを追加しているところなので、ユーザ視点からすると通常のR6RSライブラリを使うのと変わらない。
moshとして考える必要があるのは、"R6RSプログラム同士の交信でもこのようなimport libraryを(動的に)生成してパフォーマンスを確保できないか"というあたり。
予め含まれる可能性のあるシンボルを列挙した辞書オブジェクトを交換するなりなんなりの手法で"FASLテンプレート"を生成することができるかもしれない。
(辞書の交換は、不正なシンボルをチェックするためにも使える。)
クロージャのcallback
skySchemeではクロージャや継続*1をチャネルごしに受け渡し、送信先で評価した場合は送信先の環境で実行される。これは通常のschemeのセンスとは異なる動作になるが、skySchemeの目的 -- パケットのパースと構築 から考えるとこちらのほうが自然な動作なのでそうしている*2。
簡単に言えば、(変数などの環境全てを含む)クロージャを送る代わりにソースコードを送信しているイメージ。少なくとも現段階ではそのように実装していて、skyScheme処理系としてclosure->codeを持っているのでそれを利用する。
R6RS同士のクロージャのcallbackは、例えばcustom portをチャネルごしに送信したときに発生する可能性がある。R6RSの場合はクロージャは送信元の環境で実行されなければならないので、VM側に非同期に継続を実行するインターフェース(= VMのfork?)が必要になる。(あるいはskymoshのようにメッセージをformatする際にproxyを作る方法があるが。。)
