Lispを越えた先にあるもの
この前考えた内容を箇条書きにしてみた。
先に用語だけ定義しておく。
- Lispの内部動作もスタックマシンっぽい。listのネストを追う時は一旦スタックに積む動作が一番イメージしやすい。
- スタックマシンの動作は人間の脳では追いにくい。具体的には人間の脳のスタック容量はcpuと比べると非常に少ないような感じ。許容量を越えたりすると勝手にGCされる。
- だけど、人間の脳の記憶容量は優れている。これはとりあえず、人間の脳はスタックモデルではないという事を意味しているようだ。
- じゃあ何モデルなんだろう？そのモデルをベースにした新言語を作ったら人間に使いやすいんじゃないかな？
- 人間の脳は連想ゲーム的な事は得意なので、おそらく、マップ(※前述の用語定義参照)ベースのようだ。あとで後述する構造はなんだかニューロンっぽい雰囲気もする。
- じゃあ、consセルやlistの代わりに、このマップを基礎ユニットとしてソースコードを書く言語を妄想してみよう。
- ソースコードは、main関数に相当するマップの各valueに、別のマップ(へのリファレンス)が入っている、みたいな感じで、各マップを定義していく感じになりそうだ。ちょっと書きにくそうではある。各keyには、cond文の条件部的なものを入れる？
- これの実際の動作は、main関数に相当するマップに信号(継続)を送ると、そのマップの各valueに対して並列に信号(継続)が分散され、valueに設定された別マップや更にその子マップに並列に処理と環境が送られていく、みたいな感じだろうか。最近流行の並行処理にも対応できていて、いい感じだ。
- このマップの連鎖はCPS変換みたいなものなので、信号がノードの末端まで来たら、CPS変換の大元、つまり呼び出し元に末端の内容を返せばよさそう。
- という事は、この例外投げ/例外補足に近い部分だけはスタックになる必要がある。だけどそんなに大きなサイズを取る必要はない筈。
- ところで、並行処理をするという事は、このスタックもvalueの数だけ分岐する必要がある。具体的には、このスタックは多世界解釈みたいに、積まれれば積まれるほど、タコ足配線にタコ足配線を重ねるような構造になる。よって、このスタックは単純な一次元配列では駄目で、タコ足配線の分岐ができる構造のものである必要がある。これに適切なものは既にある。マップだ。
- この言語はいける！ソースコードは専用の可視化エディタでも作ればなんとかなるだろう！……とか妄想しててハッと気付いた。
- これなんて並行Prolog？
今日の結論: 自分の考える事なんて何十年も前に既に考えられていた。
だけれども、「Lispのlistの代わりに、マップを基礎構造体にしてみる」というアイデアは色々と応用が利きそうな気がするので、もうちょっと考えて遊んでみようと思う。
追記: 11のスタックだけど、よく考えたら、単方向リンクリスト、つまりconsセルによる普通のlistでも何の問題もなくタコ足配線にできる事に気付いた。多世界解釈モデルの例で行くなら、過去から見れば未来は大量に分岐してるけど、未来から見れば過去は一つだけでいいんだった。そしてスタックなので、未来から過去を辿る事ができればok。
