古くからの超漢字ユーザなら記憶の片隅にあるかもしれないスクリプト処理系「コルネット」． 業態を変えて今も活動している(って，知っていました?)，株式会社セネットが開発を進めていました． 「コルネット」は，パイロットテスト版が一部ユーザにリリースされたものの，残念ながら，陽の目をみることなく消えてしまいました．
10年の時を経て，開発に関わっていた私自身，仕様の詳細は忘れかけています． 超漢字 advent calendar という機会を得て，記録を残す意味で，どんなものだったのかをざっくりと纏めてみたいと思います．
BTRONの基本的な考え方に「データが重要である」というものがあります． 具体的なデータフォーマットとして，TAD形式が用いられています． 主張は正しいと思うのですが，正しさとは裏腹に，OS実装として存在するBTRONは，TAD操作のフレームワークが驚くほど貧弱でした． (残念ながら，2012年の今も著しい改善は為されていないように見えます．)
定形処理の自動化は，コンテンツを扱う環境を自称する以上，無くてはならないものです． プログラマでなくても，Microsoft OfficeのVBAを想像して頂けばご理解頂けると思います． AutoCAD における AutoLISP や Adobe製品における JavaScript なども，例示になります．
BTRONの歴史の比較的早期から，マイクロスクリプトは存在していました． しかし，マイクロスクリプトは昔あったハイパーカードや今の Scratch のような，動く絵本作成ツールです． TAD の操作に関しては極めて貧弱でした．(今もそうです)
この点を解決しないことには，BTRONの強みである実身仮身が訴求するのは厳しい． コルネット開発の動機は，そんな感じでした．
処理系の開発にあたっては，既にあるものを流用することも検討しました． しかしながら，BTRON仕様の特徴の一つであるTRON文字コードを活かしながら実装を流用できる言語処理系は，当時は見つかりませんでした． 結局，新規にコードを起こすことにしました． とはいっても，セネットには言語設計者はいませんでしたし，開発リソースに余裕もありませんでした． シンプルな既存言語の仕様をアレンジして使うという方針で検討を行いました．
TAD は XML のような樹形構造で表現できます．これは仕様書を見ればすぐに判ることです． また，坂村教授の…論文だったか書籍だったか忘れましたが…では，TADを操作するための TACL 言語(これもまた蒸気でしたが)が Lisp 的な表記を行なっていることが示唆されていました．
そこで，樹形構造の操作が得意といわれている Lisp 言語系のうち，軽量である Scheme を参考にした言語処理系が作られました．
処理系が扱うスクリプトは，機能付箋セグメントの固有データに埋め込まれます．
超漢字に用意されている環境では，機能付箋セグメントの内容を編集することはできません． そこで，スクリプトソースコードから実行機能付箋を生成する簡易的なコンパイラが作られました．
機能付箋から起動された処理系は，まず，その付箋が付けられている実身のレコードを吸い出します． つまり実身のレコードの数のリストができます．(後述する理由でリンクレコードを除く)
次に，レコードが TAD であった場合には，それをパーズしてリスト構造にします． ですので，この処理系では，TAD のセグメントは atom として扱われます． TAD内に仮身セグメントがあった場合には，リンクレコードと合わせて，仮身 atom となります． リスト化されたセグメントの car には，そのセグメントの種類を表す symbol が入っています．
たとえば，超漢字という文字列があった場合には，(tron-string #\超 #\漢 #\字)となります．
文章開始/終了セグメントが先についている場合には，(ts-text (begin-info) (end-info) (tron-string #\超 #\漢 #\字)といった按配です．
symbol は実は関数にバインドされているのですが，それは後述します．
実身がリスト化されたら，固有データに含まれていたスクリプトが実行されます． スクリプトには，リストの操作を行う基礎的な関数のほかに，ウインドウの操作を行うものなどが含まれています．
起動に関与した実身以外の実身をリスト化する関数も用意されました．
実身由来のリストの操作が完了したら，それを eval します．
リスト化されたセグメントの car にある symbol は関数にバインドされていると既述しましたが．
それらの関数は cdr の内容から TADバイナリを生成します．
上記の例で説明するならば，tron-string は，続く文字を結合します．
(eval (tron-string #\超 #\漢 #\字)) の結果は，"超漢字"になるわけです．
リストから TADバイナリへのシリアライズは eval を行うだけで完了します．
変なリストを作れば，TADとして正しくないものができるかもしれません．そのようなチェックはeval時に関数が行い，エラーを出します．
eval でエラーが出なかったら，TADバイナリを実身に書き出します．
…と，このような感じでコルネットは動作していました． 世の中の一部に出回ったのはα版/β版の類だったので，一部機能は欠損していたかもしれません．(もう記憶が薄い)
10年経って，あのまま開発を続けていたらどうなっただろうと考えてみたのですが，たぶん使い物にならなかっただろうと思います．
なぜならば，BTRON仕様の機能不足に早晩直面することになっていただろうからです． クリスマス前に後ろ向きな話をするのは慎み，議論の余地がない一点だけ例示することにします． document-view モデルが本質の操作環境の割に，document の更新を view に通知する仕組みが BTRON3 仕様では脆弱です．
この弱点は，個人的には BTRON 仕様の急所だと思っています． でも，まあ，アプリを作らないならば，そんなにカリカリするような話ではないのですけれども．
このようなスクリプト環境は，BTRON環境でのコンテンツ作成効率を上げるだけでなく，超漢字の基本アプリ群を置き換えるアプリを生み出す可能性を秘めています． document から view への通知は，基本アプリ群を使わずに別のフレームワークを使えれば，ある程度解消できなくもありません．
私は実現できませんでした． でも，未来永劫，誰もできないのかというと，そうでもないようにも思います． 癖のあるBTRONのGUI上でもWideStudio の動作が叶ったように，やれない話ではないはずです．
また，BTRON仕様OSを新たに書き起こすとか，Linux上にBTRON風のデスクトップを作るとかいうよりも遥かに敷居は低いものと思います．
TACL を彷彿とさせるコンテンツ処理環境，誰か達成するとよいですね． 上手く行かなかった前例として，本文が達成の参考に少しでも役に立てば幸いです．