tarosukeの日記： GUIな宣言型プログラミング環境考察

もはや言語ですらないわけだが。しかし表計算のようにテーブルを使うというのも「全部配列」なわけで困るというか(データとしての集合やデータとしては存在しない理論的な集合みたいな)各種集合を扱う必要があるのでテーブルでは力不足だ。それに頻繁に並べ換えるのでテーブルの定型さは邪魔になる。なので(GUI用語の方のテキストボックスみたいな)チップに式を書いて繋いだり並べたり内包させたりするようなのを考えてる。

そうすると、各々のチップはデータを代表していてデータに式を書いて他のデータと関係させるとなると、これはオブジェクト指向であると言える。さらにチップの種類がクラスであると解釈する事でクラスに当てはめて処理できる。クラスにはオブジェクトメンバのコンパチビリティを処理系が把握しやすいという利点がある。というわけでクラス付きオブジェクト指向、かつ各メンバは宣言型。という塩梅。

細かい内容は後回しにするとして実際の演算はどうするかと考えると、「代入」をトリガにして「代入」されたオブジェクトに依存するオブジェクトを演算する事になりそう。となると処理系の最大の仕事はオブジェクト間の依存関係をまとめる事になるかな？となると実際のコードはオブジェクト毎ではなく依存関係毎にまとまる事になりそうだ。

あとは...クラスはそれほど困難ではないし多態もクラスベースだと方法は見える。問題はエラー処理だな。言語にこれがあるとないとでは手間もソースの可読性も大違いだからな。とはいえ、エラー処理は見えてきてないな。うむむ。

それから、関数型では使う値に必要な計算しかしないけど、表計算型だと余計な計算をしてしまう可能性が大だ。実際には依存してる分だけだけど、「その先を計算する条件を定義」みたいな方法で余計な演算を防ぐ必要があるな。これは関数型が状態を持てないのに対して表計算型が宣言型なのに状態を持てる事への代償みたいなもんか。何にしても効率的な枝刈りの方法を考えねばなるまい。

...表計算型って呼称はいまいちだ。何かいい名前はないかなー。代入ドリブン？

まだあるな。代入ドリブンだと依存しているオブジェクト全部にデータが配られるわけで、大量にコピーが発生する可能性がある...いや、代入ドリブンだと手続き型と違って依存しているオブジェクトが依存されているオブジェクトを書き換える事はないから参照を使い回せばよくて、コピーを作る必要はないのかも知れん。