前書き


""良さ"に対するほとんどの評価基準 (理解の容易さ、拡張性、効率)に叶う設計の一つの例は再帰下降型構文解析器である。 これは伝統的な手続き型のコードである。 コンテナとアルゴリズムのジェネリックなライブラリである STL は、もう一つの例である。 これは伝統的な手続き型コードとパラメトリックなポリモーフィズムに決定的に依存している。"

Bjarne Stroustrup

歴史

十数年前、私は最初の計算機プログラムを Pascal で書いた。 私にとって、それは経験した中で最も忘れがたいコーディング体験だった。 相互に再起的な関数集合が文法仕様をモデルする様に、私は驚嘆した。 やがて、私が学校教育で身につけたスキルはかなり有用なものになった。 それからというもの今日に至るまで、構文解析をする仕事をいくつも課せられた。 例えば、あらゆる形式の I/O を扱う必要があるとき、それがバイナリであったとしても、 私はその仕事にいくらか形式的に次のようにあたってみる: Pascal 風の構文ダイアグラムを使って文法を書き下ろし、それからそれに対応する再帰下降型パーサを書くのだ。 その後、対応する再帰下降型パーサを書く。 この方法はとても上手く行った。

インターネットと WWW の出現で、こうした作業をする機会は桁違いに増えた。 ある時、私は Web ブラウザプロジェクトのために HTML パーサを書かなければならなくなった。 W3C の形式的な仕様をベースに動作する再帰下降型 HTML パーサは、いとも容易にできあがった。 私は HTML が形式的な仕様を持っていることに大いに感謝した。 インターネットの影響力のおかげで、私はその後さらに構文解析をしなければならなかった。 RFC の仕様はどこにでもある。 SGML 、 HTML 、 XML 、 さらに e メールアドレスや一見して自明な URL に 至るまで、どれもこれも小さな ENBF 形式の文法仕様によって形式的に規定されていた。 そんなわけで私は YACC や ANTLR と同じように、 文法仕様から自動的にパーサを組み立てる本格的なパーサジェネレータを望むようになった。 ただし、それは思い切り小さなものであって欲しい。拡張性がありながら、私のポケットに フィットするのに十分なだけ小さいもの。最も重要なゴールは拡張性だ。 e メールアドレスのようなシンプルな文法から、 XML やあるいは小型・中型のスクリプト言語のようなそれなりに複雑な文法に至るまで、 実際にパースできなければならない。

その結果が Spirit だった。 Spirit は私が日本で R & D をしていた頃に思いついた 個人のプロジェクトだった。 GoF の composite パターンと interpreter パターンに触発された私は、 プリミティブ(終端記号)とその合成物(生成規則)の 階層的なオブジェクトのコンポジション(composition)を用いて 再帰下降型パーサをモデル化できることに気が付いた。 最初のバージョンは実行時ポリモーフィックなクラスで実装された。 例えば "prod ::= {‘A’ | ‘B’} ‘C’;" のような 生成規則の文字列を与えられると、あるパーサが実行時に生成される。 コンパイル関数がパーサを コンパイル し、オブジェクトの階層構造を 動的に生成し、セマンティックアクションをその場ででリンクする。 非常に簡単なテキストは ここ で見る事ができる。

現在のバージョンは、 Todd Veldhuizen の仕事(" Expression Templates", C++ Report, June 1995)に感化されて、 式テンプレートと静的ポリモーフィズムを用いて元の Spirit パーサを完全に書き直したものである。 当初、 static-Spirit は オリジナルの dynamic-Spirit のコアのみを置き換えるものだった。 dynamic-spirit は、それ自身をなんとかして実装するためのパーサを必要とした。 元の Spirit では、入力された文法仕様文字列をパースするのに手書きの再帰下降型パーサを用いていた。

2001 年 5 月に "オープンソース" として最初のデビューをした後、 static-Spirit は成功を収めた。 2001 年 11 月には、 Spirit のウェブサイトは「活発さ」が 98% に達し、 当時の Source Forge でナンバーワンのパーサツールとなっていた。 パーサライブラリのようなニッチなプロジェクトとしては悪くない。 Spirit の"静的な"部分は忘れられ、 static-Spirit は単に Spirit となった。 間もなくそのフレームワークはより動的な機能を獲得して進化した。

このマニュアルの使い方

Spirit フレームワークはコアから始まる論理モジュールで構成されている。 このドキュメントはフレームワークの各モジュールのユーザーズガイド兼リファレンスを提供する。 たった一つのシンプルで明確なコード例は、百行のドキュメントに値する; そこで、このユーザーズガイドにはステップごとに注釈と説明のついた豊富な例が 付属している。このユーザーズガイドは例をもとにしている。大半は。

可能な限り、ユーザーズガイドの各モジュールの部分では情報を先行させること (つまり、まだ議論されていない情報の特定の一部を引用すること)は避けた。 しかし多くの場合、まだ先にある関連するトピックが議論の通常の流れの中に散在してしまうことは避けがたい。 この問題を緩和するために、"高度"なものに分類されるトピックは 初めて読む際にはスキップできるようになっている。

特定のトピックでは、その関連性を表すマークとしていくつかのアイコンが用いられている。 これらのアイコンは指し示すテキストの前に置かれる:

アイコン
Note 与えられた情報はどちらかと言うと重要であり、読者に注目されるべきものである。
Alert 与えられた情報は非常に重要である。
Detail 与えられた情報は補助的なものであるが、読者に特定のトピックへのより深い洞察を与え得る。読み飛ばしても良い。
Tip 役に立ったり助けになる可能性のあるちょっとした情報。

ドキュメントの適切な場所で、ソースコードの全体や一部が提供されている。 可読性を改善するため、ソースコードには構文に従った色づけが施されている。 このソースコードは Spirit そのものを用いて HTML に変換されたものである。 C++ から HTML へのコンバータは Spirit の配布ファイル群の一部である [ libs/spirit/example/application/cpp_to_html.cpp を参照 ] 。 cpp_to_html サンプルは、 C++ コードを HTML の CSS クラスを用いて様式化している。 このため色やフォントのスキームに自由かつ容易に手を加えることができる。

サポート

あらゆる疑問は Spirit のメーリングリストに直接どうぞ。 メーリングリストの購読はここから。 メーリングリストには検索のできるアーカイブがある。 このアーカイブへの検索リンクはSpirit のホームページに用意している。 メーリングリストは NNTP ニュースポータル から読んだり投稿することもできる(www.gmane.org に感謝)。 ニュースグループはメーリングリストをミラーしている。 次の二つはアーカイブへのリンクである: gmaneによるもの、 geocrawler によるもの。

我が愛する娘 Phoenix に
 

Joel de Guzman
2002 年 9 月



このドキュメントの対象: Boost Version 1.30.0
最新版ドキュメント(英語)