グラフィカルCUIの可能性

こういう感じのシェルを書いてました。格子の1マスを占めるタイルが単一の機能に相当し、角にある白(出力)と黒(入力)の三角を結んでデータをやりとりします。

左上にあるのが新規プロセス作成タイルで、残りは左下から流れに沿って、

という風になっています。lsとかgrepのような普通のコマンドはファイルデスクリプタ0,1,2が露出するごく標準的なものですが、文字列バッファというのがちょっと面白いかと思います。

文字列バッファというのは、入力と出力がひとつずつあって、入力されたデータは全て保存しておいて、出力側に何かつながると順次FIFOで出していく、というものなのですが、おもしろいのは保存されてる分が可視化されることです。

無名でデータをおいて置けるので、普通のshellを使っていてありがちな、なにか実行してあとからデータ欲しいが流れてしまって再現もできない、みたいなことが起きません。

今はタイルの大きさが固定ですが、タイルの大きさを可変にして、複数のマスを使うようにするのは良いかもしれません。

ウィンドウだと自由度はあるもののレイアウトが面倒、完全なタイリングでは位置に意味を持たせにくい、ということがあるので、その間をとって、かなり荒いグリッドにスナップするウィンドウというのはおもしろいかもしれません。

CUIでかなり不満なのは、画像や音声の扱いです。CUIの便利さは、流れる表示にある程度可読性があることに依存していて、これらの連続メディア、あるいはテキストでもXMLのようなものはあまりうまく扱えず、目grep的な熟練が必要、多くの場合単なるblobとして扱うことになります。

結局のところデータ型が文字のストリームだけでは不足、という話なのですが、際限ない複雑化をどう抑制するか？ということに関して↓に続きます。

標準的な文字列操作プログラム群は一種のhomoiconicityを実現していて、これが強力さを支えています。一方、ここで書いたのは(高階でない)データフロー記述であって、forのような制御構造ですら扱いに困る、という貧弱なものです。

そこで、プロセス計算、特にπ計算に目を向けてみると、チャネルを流れるのはチャネルそのもののみながら、非常に強力であることがわかります。

ここで、前の記事π算法とIOの後ろの方で使ったリテラルの扱いをふまえて他のメディアに一般化してみます。

つまり、文字は見えないチャネルの先に「実体」があり、文字のストリームはそのリンクを連続で送っている、と見ると、その他のメディアでも、どこかに実体を用意して、その一側面を表すリンクを送ればよい、ということになります。

だいたいどのような記号系でも、意味は構造にのみ存在するのですが、π等のよいところは、その一部分を簡単に現実に接地できることです。