僕は，独特な研究を色々とやってきてるんですが．例えば僕がD論で書いたのは，インターネットのような絶対アドレスを使わないで，相対アドレスで世界中を繋ぐという方式の提案だったし．「未来の電話」で検索すると出てくると思いますが，テレビ電話のまったく新しいディスプレイの配置法を考えたし．「コンピュータ」という名前の特許を書いたこともあって，これはCPUの命令セットを人間が設計するんじゃなくて，圧縮アルゴリズムで決めればいいのに，というものです（この特許は書いただけで審査請求はしていませんが)．とにかく，何かを考えるときに究極の姿を追い求める姿勢だったと思います．
今から20年くらい前の話ですが，研究の世界で流行っていたキーワードに「オープンシステム」と「マルチエージェント」というのがありました．インターネットはありましたけど，まだWebの爆発が起きる前です．このインターネットの上で動くシステム，日本語で言うと「非均質開放分散系」とか言ってたかな．オープンシステムというのは，簡単に言うとビーカーに液体が入っていてそこにフタをしないものです．いろんな分子が液体に入り込むし，液体も蒸発して中の分子が出て行ったりする．何が入って，何が出て行くかを監視できないような状態です．それをどうやって記述するかということに興味がありました．
プログラミング言語の記法（書き方）について考えてみます．文法というのがあって，それを守るように書くと，コンピュータが間違わずに解釈できて，人間が書いた意味を理解してくれる．そしてその文法は，木構造をしています．木構造をしていない文法はあるのかなぁ．木構造というのは，たとえば，こういう式があったとき，
3 * (4 + 5)
これをコンピュータが解釈すると
のような構造になります．一番上にかけ算が来て，それを3と何かとでかける．何かというのは，足し算で，それは4と5を足す．基本的にすべてのプログラミング言語はこんな感じで木構造をしています．
ところが，オープンシステムというのは，いろんなものが出入りするシステムなので，こういった木で表現することはできないんですね．いま，出来ているように見えているのはどっかをごまかしているからだけです．ではどういう書き方をしなければ行けないか．たとえばこんなことなんじゃないか，と考えたのが，次のような書き方です．
( a { b ) c }
これです．括弧の対応があっていませんがそれでいいんです．「（）」で考えるとa b がグループですが，「{}」で考えるとb c がグループです．ほ乳類と泳ぐ生き物という集合を考えると
( 犬 { くじら ) マグロ }
みたいになります．
で，オープンシステムですが，こんな感じに書きます．
a { b ) c d
なんと，「()」の開き括弧がありません．それと「{}」の閉じ括弧もありません．こういったファイルがあったときに，a b や b c d はこのファイルの中で閉じていなくて，外側に何が来るかによって変わってしまう，という記述なのです．ファイルの隣というのはどう定義するのか，そのファイルが置いてあるディレクトリの辞書順で隣にあるものなのか．とにかく，オープンシステムで何かを記述するということは，こんな記法を発明して行くことなんですね．．
この書き方は，テキストでオープンシステムを表現するというものでしたが，テキストは1次元にならんだ文字の並びですから，オープンシステムの広がり具合が1次元に限定された記述とも言えます．実際は2次元・3次元などでは表現できない大きな次元で広がって行きますから，こんな1次元での書き方なんて発明してもご利益はほとんどないのですが，それでも思考実験としては面白いです．
きっかけはオープンシステムをどう記述するかだったのですが，考えてみると，今のテキストによる言語は木構造の文法に支配されすぎていて，いろいろと不自由だということがわかりました．そこで，もう少し色々な記法を考えて，たとえば括弧の半閉じ，半開きという記法も発明しました．
(a { b |) c (| d ) e}
|) は半閉じ括弧で，完全には閉じません．(|が半開き括弧で，さっき半分だけ閉じた括弧をまた開きます．括弧のスコープを飛び飛びであけたり開いたりできます．何のために必要なのかはともかくね．
一般のプログラミング言語はほぼすべてテキストで表現されています．それらの言語は複雑な意味を扱うので，実はとても木構造では表しきれないくらい複雑な構造を取り扱っているのですが，しかし表現する文法が木構造に限定されているために，複雑な構造をどうやって木構造に組み込んで表現するか，という工夫が盛んに行われるようになりました．
たとえば，先ほどの式は関数型言語では，こうかきます．
*(3, +(4, 5))
先ほどの式の木構造にすごく似ている書き方をします．一方で，Prologという不思議な言語でこの式を書いてみると，
*(3, A, Root)
+(4, 5, A)
のようになります．これは，3とAを足した物をRootにする．4と5を足したものをAにする．と読みます．関数型言語では，計算の値の流れが重要なので，その流れと，テキストの文法の木の枝のつながり方を対応させます．Prologでは計算の値よりも，計算が成功したか失敗したかということを重用しするので，その成功失敗の流れを，テキストの文法の木の枝に対応させています．そうすると，計算の流れについては木の枝で表現できないので，Aという変数を介して行うようになります．
テキストの言語では，一番重要な流れをテキストの木構造の枝の付き方で表現して，それ以外の犠牲になる部分には，同じ名前をつけてそこで流れを表現しています．
機械語の頃は，メモリーの命令の並びがそのままテキストでの命令の並びでした．gotoというかジャンプ命令はメモリーのすきな番地に処理が移動することですが，人間は単純な数字にとくべつな意味を持たせて考えるのは非常に苦手なので，番地の数字の代わりにラベルをつけて，人間が考えやすいようにしています．ラベルというメモリー上の印と，そこへ移動する命令で，プログラムはぐちゃぐちゃになってしまいまして，それをなんとかしようということで，goto文が悪者になりました．色々なプログラムを見てみると，goto文とif文とで同じようなプログラムのパターンが見えてきます．そのパターンに名前をつけたのがwhile, do until といった制御文になったというわけです．
実は，プログラミング言語にはもっといろんな流れを表現しなければなりません．たとえばファイルをオープンしたらクローズしなければなりません．あるリソースに対して，特定のパターンでアクセスする必要があります．本来ならそのパターンの部分を取り出して，それをテキストの木構造にあてはめて記述するようにしなければなりません．そうすると，そのリソースへのアクセスのパターンのエラーが劇的に減るはずです．ところが，テキストは単一の木構造しか表現できないため，ファイルのために貴重な木構造を使ってしまうと，他のものを犠牲にしなければなりません．そんなわけで，値の流れと，制御の流れ，というのからなかなか離れることができずに，新しい書き方の発明がなかなか進んでいないのでしょう．エラー処理とかはそれでも頑張っているのかな．
プログラミング言語は進化して，色々と複雑な流れを一度に記述しなければならなくなってきているのにも関わらず，それを表現する形式がテキストに限定されているのは，プログラミング言語の研究の妨げになると考えました．そんな感じで，ビジュアルプログラミングに興味を持って行ったのでした．
僕は最初から子供向けを作ろうと思ってビジュアルプログラミングをやっていたのではなくて，ものすごく深い話を考えるためにビジュアルプログラミングに進んだわけです．まあでもこういうのは，難しいのでがんがん研究が進むわけでもなく，ちょっと煮詰まってきたところで，いろんな表記法や計算法を発明したので，ちょっと視点を変えてそれらのノウハウを集めて言語をつくってみようか，ってことで力を抜いて作ったのがビスケットなのです．
今から20年くらい前の話ですが，研究の世界で流行っていたキーワードに「オープンシステム」と「マルチエージェント」というのがありました．インターネットはありましたけど，まだWebの爆発が起きる前です．このインターネットの上で動くシステム，日本語で言うと「非均質開放分散系」とか言ってたかな．オープンシステムというのは，簡単に言うとビーカーに液体が入っていてそこにフタをしないものです．いろんな分子が液体に入り込むし，液体も蒸発して中の分子が出て行ったりする．何が入って，何が出て行くかを監視できないような状態です．それをどうやって記述するかということに興味がありました．
プログラミング言語の記法（書き方）について考えてみます．文法というのがあって，それを守るように書くと，コンピュータが間違わずに解釈できて，人間が書いた意味を理解してくれる．そしてその文法は，木構造をしています．木構造をしていない文法はあるのかなぁ．木構造というのは，たとえば，こういう式があったとき，
3 * (4 + 5)
これをコンピュータが解釈すると
のような構造になります．一番上にかけ算が来て，それを3と何かとでかける．何かというのは，足し算で，それは4と5を足す．基本的にすべてのプログラミング言語はこんな感じで木構造をしています．
ところが，オープンシステムというのは，いろんなものが出入りするシステムなので，こういった木で表現することはできないんですね．いま，出来ているように見えているのはどっかをごまかしているからだけです．ではどういう書き方をしなければ行けないか．たとえばこんなことなんじゃないか，と考えたのが，次のような書き方です．
( a { b ) c }
これです．括弧の対応があっていませんがそれでいいんです．「（）」で考えるとa b がグループですが，「{}」で考えるとb c がグループです．ほ乳類と泳ぐ生き物という集合を考えると
( 犬 { くじら ) マグロ }
みたいになります．
で，オープンシステムですが，こんな感じに書きます．
a { b ) c d
なんと，「()」の開き括弧がありません．それと「{}」の閉じ括弧もありません．こういったファイルがあったときに，a b や b c d はこのファイルの中で閉じていなくて，外側に何が来るかによって変わってしまう，という記述なのです．ファイルの隣というのはどう定義するのか，そのファイルが置いてあるディレクトリの辞書順で隣にあるものなのか．とにかく，オープンシステムで何かを記述するということは，こんな記法を発明して行くことなんですね．．
この書き方は，テキストでオープンシステムを表現するというものでしたが，テキストは1次元にならんだ文字の並びですから，オープンシステムの広がり具合が1次元に限定された記述とも言えます．実際は2次元・3次元などでは表現できない大きな次元で広がって行きますから，こんな1次元での書き方なんて発明してもご利益はほとんどないのですが，それでも思考実験としては面白いです．
きっかけはオープンシステムをどう記述するかだったのですが，考えてみると，今のテキストによる言語は木構造の文法に支配されすぎていて，いろいろと不自由だということがわかりました．そこで，もう少し色々な記法を考えて，たとえば括弧の半閉じ，半開きという記法も発明しました．
(a { b |) c (| d ) e}
|) は半閉じ括弧で，完全には閉じません．(|が半開き括弧で，さっき半分だけ閉じた括弧をまた開きます．括弧のスコープを飛び飛びであけたり開いたりできます．何のために必要なのかはともかくね．
一般のプログラミング言語はほぼすべてテキストで表現されています．それらの言語は複雑な意味を扱うので，実はとても木構造では表しきれないくらい複雑な構造を取り扱っているのですが，しかし表現する文法が木構造に限定されているために，複雑な構造をどうやって木構造に組み込んで表現するか，という工夫が盛んに行われるようになりました．
たとえば，先ほどの式は関数型言語では，こうかきます．
*(3, +(4, 5))
先ほどの式の木構造にすごく似ている書き方をします．一方で，Prologという不思議な言語でこの式を書いてみると，
*(3, A, Root)
+(4, 5, A)
のようになります．これは，3とAを足した物をRootにする．4と5を足したものをAにする．と読みます．関数型言語では，計算の値の流れが重要なので，その流れと，テキストの文法の木の枝のつながり方を対応させます．Prologでは計算の値よりも，計算が成功したか失敗したかということを重用しするので，その成功失敗の流れを，テキストの文法の木の枝に対応させています．そうすると，計算の流れについては木の枝で表現できないので，Aという変数を介して行うようになります．
テキストの言語では，一番重要な流れをテキストの木構造の枝の付き方で表現して，それ以外の犠牲になる部分には，同じ名前をつけてそこで流れを表現しています．
機械語の頃は，メモリーの命令の並びがそのままテキストでの命令の並びでした．gotoというかジャンプ命令はメモリーのすきな番地に処理が移動することですが，人間は単純な数字にとくべつな意味を持たせて考えるのは非常に苦手なので，番地の数字の代わりにラベルをつけて，人間が考えやすいようにしています．ラベルというメモリー上の印と，そこへ移動する命令で，プログラムはぐちゃぐちゃになってしまいまして，それをなんとかしようということで，goto文が悪者になりました．色々なプログラムを見てみると，goto文とif文とで同じようなプログラムのパターンが見えてきます．そのパターンに名前をつけたのがwhile, do until といった制御文になったというわけです．
実は，プログラミング言語にはもっといろんな流れを表現しなければなりません．たとえばファイルをオープンしたらクローズしなければなりません．あるリソースに対して，特定のパターンでアクセスする必要があります．本来ならそのパターンの部分を取り出して，それをテキストの木構造にあてはめて記述するようにしなければなりません．そうすると，そのリソースへのアクセスのパターンのエラーが劇的に減るはずです．ところが，テキストは単一の木構造しか表現できないため，ファイルのために貴重な木構造を使ってしまうと，他のものを犠牲にしなければなりません．そんなわけで，値の流れと，制御の流れ，というのからなかなか離れることができずに，新しい書き方の発明がなかなか進んでいないのでしょう．エラー処理とかはそれでも頑張っているのかな．
プログラミング言語は進化して，色々と複雑な流れを一度に記述しなければならなくなってきているのにも関わらず，それを表現する形式がテキストに限定されているのは，プログラミング言語の研究の妨げになると考えました．そんな感じで，ビジュアルプログラミングに興味を持って行ったのでした．
僕は最初から子供向けを作ろうと思ってビジュアルプログラミングをやっていたのではなくて，ものすごく深い話を考えるためにビジュアルプログラミングに進んだわけです．まあでもこういうのは，難しいのでがんがん研究が進むわけでもなく，ちょっと煮詰まってきたところで，いろんな表記法や計算法を発明したので，ちょっと視点を変えてそれらのノウハウを集めて言語をつくってみようか，ってことで力を抜いて作ったのがビスケットなのです．