再開ベースのIOシステム？

私は最近、主にAbramskyの古典的な論文Retracing Some Paths in Process Algebraからの再開をいじっています。それらは非常に洗練されており（基本的にはドメイン方程式R = I → （O × R ）の解）、カーンネットワークを非常に連想させます。$R = I \to (O \times R)$

もちろん、この観察は私には元々ありません---それらは追跡されたモノイドカテゴリを形成し、この事実は線形論理に意味論を与えるためにAbramskyとJagadeesanによって使用されました。いずれにせよ、再開にタイプIの入力を供給すると、タイプOの出力と更新された再開r ′が得られることに注意してください。これにより、データフローノードが入力を見ると変化するという事実をモデル化できます。お入りください。$r$$I$$O$$r'$

結果として、MLやHaskellなどの高次言語でI / Oトランスデューサーを構築するための優れたAPIを提供できるように思えますが、そのようなことを説明する論文は見つかりません。しかし、彼らは何十年も前から存在していて、ゴードン・プロトキンがそれらを発明したので、彼らが曖昧にだまされてきたようではありません。だから、誰かがそのような用途に使用されているのを見たことがあるのではないかと思いました。

これは、機能的なI / Oシステム（または、Freshman Kidsの楽しみ）で Felleisenらが説明したI / O APIによく似ています。基本的には、一連のイベントハンドラーを（より単純な非分散設定で）記述します。各イベントハンドラーは、現在の状態を受け入れ、更新された状態を返します。最後に、to-draw各状態の「出力」を生成するハンドラーがあります。

このAPIを少し再キャストすると、ハンドラーと現在の状態を一緒にパッケージ化でき、ハンドラーが新しい状態と新しいハンドラーのセットの両方を返すたびに、この状態と操作のパッケージを「オブジェクト」と呼ぶかもしれません。:)次に、結果をこのオブジェクトと「出力」のペアにすると、正確に再開の種類がわかります。

興味深いことに、この論文では、Felleisenらが分散設定に移行するときにこれを正確に実行します。すべての操作は、システムの他の参加者に送信されるメッセージの形式で新しい状態と「出力」のペアを返します。

この投稿に出くわしました。

1980年代初頭に戻ってください。Friedman et al @ Indianaは、スキーム84（スキーム48ではない）のコンテキストで「エンジン」の概念を発明しました。エンジンは、おおよそこのタイプの要素です。

E = Unit x Nats -> E + O

Unitの代わりにIを使用することもでき、x Nats部分はオプションです。これらは再開の一種と考えることができ、コンテキストエンジンによっては再開よりも実用的です。