FUTURE WORKS... (あるいはつぶやき)
試してみてだめだったこと
- スタックのパラメータ化
-
Allocator::rebindのような感じでできることはできるが、シンプルさに欠けるように思われた - スタックをパラメータ化して嬉しいことはまずないだろう……
難しくなさそうなこと
- パーサの永続化
- 使う場所を想像できないが、できることはできる
- 文法/表の可視化/XML化
- 基本的にはgeneratorの亜種だと思う
- boost.graphにブチ込んでgraphvizとかで出力したらそれで終わりな気がしなくもない
大変そうなこと
- GLRパーサ
- すでにGLRパーサの 時代かもしれませんが( Elkhound, D Parser, bisonの派生物などが実装している )、
- いろいろと問題点がありそうなので解決する気力がありません。
- EBNF
- むずかしくはなさそうだけど、
- セマンティックアクション起動の仕様に問題が……(リストをどう扱うべきか……)
- こんな感じ？
struct SemanticActin {
int DoAction1( const parser::Sequence< T >& s ){}
int DoAction2( const parser::Optional< T >& s ){}
}
- と思ったけど
(Foo Bar Baz)*って感じの文法がうまく扱えない - スキャナーレスパーサ
- 使い勝手はとてもよいが、デメリットも……
- →スキャナーレスってことは、トークンがcharってことになる。
- →正規表現=>caper文法変換コードみたいのがいるかな？
- →出力パーサ内で
boost::variantを使ってよければ結構簡単にできるかな？ - →テーブルが馬鹿でかくなる恐れは？
- →分離していることのメリットも結構あるかも……
-
boost::regexにマッチアクションみたいのがあるとよかったんだけどね。 - 現状の
boost::regexだと、どのパターンにマッチしたのかO(1)で判定できないのでscannerにはいまいち向いてない。 -
replace_matchでトークン番号に変換するとかでむりやりできないかな？ - scannerだけspiritを使うというのもアリかな。
-
boost::tokenizerで大概は大丈夫かなあ？ - ASTの自動生成
-
boost::variantが思ってたよりもいいものだった - caperのcpgくらい情報があれば、
boost::variantを用いたASTの自動生成もできるかも？ - と思ったけどそんな楽でもないか
改良したいこと
- 動的パーサエンジン
- インターフェイスがイマイチで自分でもよくバグを出すので直したい。
その他
意見きぼん
- このコンパイラでこういうオプションつけるとwarningがでる
- ソースのここはboostのごにょごにょを使ったほうがいい
- ここはこうすればもっと{クリーンになる|拡張性があがる}
- こうしたいんだけどうまくいかない、なんとかなんない？
- エラーメッセージの意味がわからない
- エラーメッセージの英語が間違っている
- コンポーネントの名前が直感的でない
とかそういうささいなことでもOK 匿名でもOK
うまく動かない文法ファイルができあがったら、コメントに「動かない」と書いて挨拶抜きで貼り付けてくれるだけでも嬉しいです。こちらでなんとかします。もちろん条件を特定してもらえればそれはそれで嬉しいですが。(ただし、もともとBNFがLALR(1)的によろしくない場合の対処は保証しかねます。)