表示調整
閉じる
挿絵表示切替ボタン
▼配色
▼行間
▼文字サイズ
▼メニューバー
×閉じる

ブックマークに追加しました

設定
0/400
設定を保存しました
エラーが発生しました
※文字以内
ブックマークを解除しました。

エラーが発生しました。

エラーの原因がわからない場合はヘルプセンターをご確認ください。

ブックマーク機能を使うにはログインしてください。
21/46

第21話 研究集会(3)~ニッチな研究~

ニッチな研究だって意義があるかもしれない、みたいなお話です。この辺は、研究だけじゃなくて、他の媒体についても同じことが言えるのかなと思ったりします。

 編集委員会を挟んで次の発表の時間になる。今日の発表は先程の2つに加えて、次の発表でラストだ。LANGの研究集会でどれだけ発表や論文投稿が集まるかは、開催地や時期にも寄る。今回は今日3件、明日2件と比較的少ない。


「それでは、次の発表に移りたいと思います。北海大学(ほっかいだいがく)浅海佳子(あさみよしこ)さん。よろしくお願いします」


 セッションの座長がそう言って、発表が始まった。


「どうも、北海大学の浅海です。本日は、『メタ構文解析器生成系MPGの提案』と題した発表を行いたいと思います」


 少し緊張した様子で、発表を始めた浅海さん。名前も聞いたことがないし、研究発表が初めてのB4の人だろうか。


「まず、皆さんご存知だと思いますが、現在、構文解析器生成系は非常に一般的に使われるようになっています。特に、古くからあるのでYaccやその再実装であるGNU Bisonは皆さんご存知のことかと思います」


 スライドには、Yacc(LALR(1)), ANTLR(ALL(*)), JavaCC(LL(1)), Coco/R(LL(1)), Elkhound(GLR), Rats(Packrat Parsing)などの名前がリストアップされている(※すべて実在のものです)。構文解析器生成系というのは、構文解析器というソフトウェアを生成するためのソフトウェアで、構文解析器を一から書かなくても、簡易な記述からそれを生成してくれる。


「《《当然の事ながら》》、構文解析器生成系が生成できるソースコードの言語は固定です。たとえば、YaccはCのコードを吐きますし、JavaCCはJavaのコードを吐きます。ANTLRなど、複数の言語を切り替える仕組みがあるものもありますが、多言語対応の構文解析器生成系は少ないですし、そのためにコストもかかります」


 しかし、当たり前じゃないことを当たり前のようにして話す辺り、ちょっと変わった人だ。もちろん、研究に慣れていない人が、必要な前提知識を《《うまく説明できない》》のはよくあることなのだが、「これ知ってますよね」というノリでガンガン言っていくのとはちょっと違う。


「そこで、私が考えたのが、多言語対応の構文解析器生成系のアプローチをより進めて、構文解析器生成系自体を生成する事で、多言語対応を容易にするアプローチです。これを、メタ構文解析器生成系(MPG(Meta Parser Generator))と呼ぶことにします」


 なるほど。発想はわかる。しかし、構文解析器生成系をさらに生成するソフトウェアという《《メタ》》なアプローチを進める辺りは、ちょっと独特だ。正確には、構文解析器生成系自体が《《メタ》》なものなので、《《メタメタ》》といったところか。


「さて、MPGの実現をするにあたって問題となるのは、MPG自体の構文です。MPGの目的は、構文解析器生成系自体を生成することですから、《《構文解析器生成系そのものを生成できる》》ような記述が必要になります」


 その言葉を聞いた瞬間、背筋がゾクりとするのを感じた。今まで、全く考えたこともない事だったからだ。Java言語の文法を考えるのはわかる。構文解析器のための文法を考えるのはわかる。しかし、構文解析器を生成するための文法というのは、意表を突かれた。というか、何を考えればいいのかがまずわからない。


「まず、最も簡単な構文解析器生成系を生成するための記述を考えます」


 と言って提示された図だが、一瞬では何を言っているのかわからない。何を言いたいのかわからないのではなくて、言っている事が難解なのだ。


 理解に躓いている間にも発表は進み、


「というわけで、あくまで途中実験ではありますが、LL(1)構文解析器生成系を生成するための記述を、主要な言語に対応させるための記述量を抑えることができました。まだ発展途上ではあるのですが、今後は、多種多様な構文解析アルゴリズムに対して、このアプローチが本当に適用可能か考えてみたいと思います」


 と締めくくられた。


「それでは、何か質問のある方はいますか?」


 座長が質問を求める。根幹の部分はわからなかったが……


洛王高校(らくおうこうこう)の織田です。興味深い発表ありがとうございました。一つ質問があるのですが、構文解析器ならともかく、構文解析器生成系を作る人というのは非常に少数だと思います。MPGのような大掛かりな仕組みを作ってまで、記述コストを追求する必要があるのでしょうか?」


 問題意識はわかるが、需要が少ないのではないかという感想を俺は持った。


「そうですね。おっしゃる通り、一般的にはそこまで重要視されないと思いますし、ニッチな話だと思います。また、途中段階なので、このアプローチが良いのかはわかりません。しかし、特に新しい言語において、構文解析器生成系が無いために、手書きの効率の悪い構文解析器を記述せざるを得ない場面があります。そういった場面で、素早く新しい言語に構文解析器生成系が対応可能というメリットがあるのでは、と考えています。どうでしょうか?」


「なるほど、理解しました。ありがとうございます」


 着席して、少し考える。それでも、やはりこれを必要としている人は少ないのではないかと思うが、俺たちの研究だってそういう部分は少なからずある。「構文解析は解決された問題だ」という人だって居るくらいだ。だから、ニッチだからというのは研究を否定する理由にはならない。


 改めて、研究というものの意義について思いを馳せられるような発表だった。

評価をするにはログインしてください。
ブックマークに追加
ブックマーク機能を使うにはログインしてください。
― 新着の感想 ―
[一言] yacc/lexのペアって、もう生きた化石みたいなものかと思っていましたが、まだ使われているのかな。lexは実用的には非効率だけれど、yaccは案外効率的なコード生成するので実用に耐える、と…
感想一覧
+注意+

特に記載なき場合、掲載されている作品はすべてフィクションであり実在の人物・団体等とは一切関係ありません。
特に記載なき場合、掲載されている作品の著作権は作者にあります(一部作品除く)。
作者以外の方による作品の引用を超える無断転載は禁止しており、行った場合、著作権法の違反となります。

この作品はリンクフリーです。ご自由にリンク(紹介)してください。
この作品はスマートフォン対応です。スマートフォンかパソコンかを自動で判別し、適切なページを表示します。

↑ページトップへ