複雑なデータ構造を可変長の構造体にマッピング。
それが進化(退化)するとクラスのインスタンスにマッピング。
後者は退化だと思います。だって、相互にポインタを持ったりしてぐちゃぐちゃですもん。
せいぜい、共通の基底クラスを持っていて共通の操作を共通のメソッドでおこなえるような仕組みがあるくらいのことで、ハナモゲラ度には変わりありません。
たとえば、C/C++のプログラムを木構造のXMLで記述しようとしないのと同じように、物事には向き不向きがあります。
教科書的コンパイラではDAGで内部表現する模様。
木構造のようで、木構造ではないものを記述する実践論は、何十年も前から目の前にあるわけです。
それを複雑怪奇なクラスインスタンスの網目模様で構成したってしかたがありませんやね。
boostのグラフライブラリを見ればわかるように、グラフをC++でエレガントに書くことは自己満足でしかありません。ちょっと大きくなるとメモリを食いすぎ、ちょっと凝ったアルゴリズムを書くとデバッグ不能に陥る。
構造体で双方向リンクトリストを作って、Visit関数をちまちま書いた方が余程簡単です。
さて本題です。PostScriptがプログラミング言語であるように、データがプログラムであっても良いわけです。もっとも身近な例は今挙げたPSです。身近でない例として恐ろしく普及しているのは、NCプログラムです。NCプログラムはプログラムですが、NCデータと言われることもあります。
紙テープのパンチ穴が主役だったころからいまだに現役でいられる理由はずばり、これがデータではなくプログラムだからでしょう。
同じ産業用ロボットでも、ISO(ANSI)風のNCプログラム駆動のものと、どっかのベンチャが作ったしょうもない言語のものとでは、つぶしの効き具合が全く違います。
NCプログラムにも欠点は多数あるでしょうが、NCプログラムとは、機械制御や、機械加工における、五線譜のようなものです。楽器が異なっても、同じように読める、書ける。同じように弾ける。
別の視点を持てば、NCプログラムは低レベルのフォーマットでしかないのかもしれません。
ブロック単位の記述、アルファベットによるアドレッシング。真髄はただそれだけです。
XMLのように拡張性は必要ありません。NCプログラムは、実体を持つ機械制御のためにあるからです。XYテーブルなら2軸の制御が記述できればよいのです。サルでもわかります。
全く未知の機械を目にしても、軸数を数えNCプログラムを眺めれば意味は理解できます。
NCプログラムで簡単に書けることを遠回りして実現しているものの何と多いことか。
そして、なぜデータでなくプログラムであることが優位に働くのかについては触れないままエントリは終了していくのです・・・
