１．担当ＰＭ

　竹内　郁雄 　　（電気通信大学教授）

２．採択者氏名

３．プロジェクト管理組織

　株式会社　創夢

４．委託支払金額

　2,320,000円

５．テーマ名

　Kisp: WiKi風DSLを簡単に定義・解析・利用するためのシステム (For グッドラッパー)

６．関連Webサイト

　なし

７．プロジェクト概要

　開発者でもサーバ管理者でもない一般ユーザにとって，コンピュータは難しすぎる．やりたいことは沢山ある．メールマガジンを書きたい，図を描きたい，リファレンスマニュアルを書きたいなど．しかし，そのような要求をテキストデータとしてどう表現すれば良いのか分からない．たとえ分かったとしても，その冗長で複雑怪奇なありさまに嫌気がさして，挫折してしまうに間違いない．

　上記のような要求を表現するための問題領域向け言語 (DSL ， Domain Specific Language) は要求の数だけ存在する． DSL と聞いて即座にイヤな顔をする人もいる，近年では「 DSL= 設定ファイル = バッドノウハウの巣窟」という図式が成り立っているからであろう．一般ユーザ向けの DSL として成功したものといえば WiKi 位しか見当たらない．

　果たして WiKi 風 DSL は一般ユーザと開発者とコンピュータの接点として最適なのであろうか？一般ユーザとしては， WiKi 程度の複雑さなら Blog をやっているうちに慣れると思われる．また，マークアップの字句・構文定義を自分好みに変えることができれば満足してもらえるであろう．ただ，そうなると開発者側やコンピュータの負担が多くなりそうである．

　その負担の大部分を解決しようというのが，今回提案する Kisp システムである．開発者は猥雑な字句・構文解析から開放され，解析済みの構文木を処理するフィルタの開発に専念できるようになる．処理系は Lisp 方言である Gauche を使うが，構文木は S 式だけでなく XML でも出力できるので，他言語とのやりとりも簡単である．

　WiKi は html に対するグッドラッパーであった．それと同じように， WiKi 風 DSL が dot ， sgml ， texi ， tar などに対するグッドラッパーに成り得るはずだと，私は確信する． Kisp を普及させ，一般ユーザと開発者が創造的な問題に集中できるようにすることが，この提案の目的である

８．採択理由

　 オーディションで，この提案はビジネスになりにくいよというコメントも出ていたが，フリーのプログラマでありながら，このような提案をしてくる平内君の心意気に感心した． Kisp 自身が実際にどのような使われ方をするのか， Wiki などに疎い竹内は実はいまいちわかっていないのだが，タグの嵐に悩まされないこのような言語体系をもう一度世の中に認知させることは重要である．

９．成果概要

　Kisp とは，構造化されたプレインテキストを構文定義に従って構文解析し，構文木を出力するためのミドルウェアである．次のような特徴がある ( 図 1) ．

・ 扱える構文とマークアップが豊富である．

・ ユーザーが自由に構文を定義できる．

・ 文章要素ごとに構文を定義できる ( 構文定義の入れ子が可能 ) ．

・ 構文木の妥当性が検証できる (RELAX NG 相当 ) ．

・ BSD ライクライセンスである．

　プロジェクトでは以下のものを作成した．

・ Kisp パーサ

・ 投票相関図生成アプリ Jinvot

　データのテキスト表現として XML が主流であるが，タグが多すぎて見苦しく，エディタで編集するのも困難である．タグの問題を解決するために YAML というフォーマットが考案されたが，ユニコード限定であり，構文も問題領域以上に複雑である．ところで，近年一般に浸透しつつある Wiki や Blog のデータテキスト表現は，非常にシンプルで書きやすく，分かりやすい．この種の構文を専門に扱う構文解析器があれば，シンプルで書きやすいテキスト表現をマンマシンインタフェースとして広く活用することが出来る． Kisp はまさに Wiki 風構文専門のパーサである．

平内　図 1 Kisp 全体の構造

開発した二つのソフトウェアの詳細は以下の通り．

(1) Kisp パーサ関連 (Kisp モジュール )

　ユーザー定義の構文によって，一般的な Wiki や Blog のテキストデータを構文解析することができる．ただし，開発期間中にはインデントによって階層化したテキストデータの構文解析のみのサポートが完了した．

　サポート範囲が狭くなってしまったのは， Kisp の言語仕様をプロジェクト途中で大幅に増強改訂したために，実装の大幅な手戻りがあったためである．当初の仕様では，多様な要求を満足できなかった．

Kisp が出力した構文木を Kisp アプリに合わせて加工するためのフィルタ群の開発を行なった．ここで， validator は RELAX NG の Haskell によるリファレンス実装をそのまま Scheme に移植した．また， S 式を XML に変換するためのモジュールは， Gauche に組み込まれていたのでそれを利用した．

(2) 投票相関図生成アプリ (Kisp アプリ )

Kisp の応用例として，既存の図形生成アプリ (dot) を利用した投票相関図生成アプリを作成した ( 図 2 ，図 3) ．これは， dot のような猥雑なデータ形式に対するラッパーをどのように作るかをユーザに示すためのサンプルプログラムである．その仕組みを図 4 に示す．

平内　図 2 ネットワークゲーム人狼での投票例

平内　図 3 それをベースにした投票相関図

平内　図 4 投票から投票相関図が生成される流れ

１０． ＰＭ評価とコメント

　自然な日本語で箇条書的な構造を書けば，それを自動的に計算機処理可能な形に構造化してくれて，いろいろなアプリ (HTML ， MM ， TEXI ， etc) にそのまま食わせることができるようにしようという提案である．今日的にはこれは XML の専売特許みたいなことになっているが，あのような面倒な言語を使わずとも，日常的な日本語で，ほんのわずかの構造化意識が書き手にあれば，それをベースに実にいろいろなことができるはずだ．

　実際，平内君の提案文書の大半が ( 当時の仕様の ) Kisp 言語で書かれていた． PM のように昔から Lisp の S 式さえあれば，もうなんでもできちゃうと脊髄レベルで思っているような手合いにはピンと響く話であった．というわけで，採択時点では話を聞いて，これは面白そうだ，フリーランスでこんな意気込みをもってやっていこうというのは見所があると考え，「ぜひ採択」とした．

　しかし，残念ながら，プロジェクトは完成度を高める余裕がなく終了した．その最大の原因は， Kisp 言語仕様をプロジェクトのちょうど半ばごろに抜本的に増強したことにある．そのため，既存のプログラムの多くが無駄になり，多くの手戻りが発生した．そこでファイト一発が出ればよかったのだが，むしろ開発プロセスを萎縮してしまった時期があったようだ．

　とはいえ，改訂された Kisp 言語は，実に多様な文書構造に対応できるようになっており，これだけできれば，もうほとんど問題ないよ，というレベルになっている．実装はその一部しかできなかったが，図 1 の全体構造のモデルとなるような実装は図 4 に示したとおり完成している．だから，提案の意味を実証できる最低限のところには至った．

　あとは平内君も望んでいるとおり， Kisp パーザを完成させ， Wiki の Kisp 版であるところの Kiswiki を公開できるところまでなんとかもっていってほしい．平内君がフリーランスのプログラマとしての自己基盤をしっかりさせるためにも，今後の開発続行を切に希望する．