SableCCの続報です。
SableCCはよくできているな、と思います。が、ここでは問題点を指摘しましょう。利点はSableCCサイトやそこにある文書でアピールされていますから。
問題点その1
入力から構文木の生成までは、すべてSableCCフレームワークコードが行います。構文エラーは例外によりユーザーコード側に知らされますが、解析を続行することはできません。よって、エラーをスキップしたり修復して、続きを読みにいくことはできません。
つまり、構文エラーに出会うとその時点で必ず停止してしまいます。場合により、この動作は許容できないものでしょう。
yaccやJavaCCでは、アクションを使ってエラーのスキップや事後処理を記述できます（とても泥臭いが）。
問題点その2
自動的に生成される木は、抽象構文木（AST; abstract syntax tree）と呼んでますが、これはウソで、まったく抽象化されてません。so-called ASTの実態は解析木（parse tree, parsing tree）です。
例えば、sum(3, 5) に対して次のような木ができれば抽象構文木と呼んでいいでしょう。
親:関数sumの呼び出し
子1:第1引数3
子2:第2引数5
が、（生成規則の書き方にもよりますが）実際にSableCCが作るのは：
親:関数呼び出し
子1:関数記号sum
子2:左括弧(
子3:数3
子4:カンマ,
子5:数5
子6:右括弧)
補助記号である括弧やカンマもすべてノードになってしまうのです。これは相当に鬱陶しいハナシになります。概念的な木ではないので扱いにくいし、パフォーマンスにも悪影響を与えます。
開発中のバージョン3では、この問題を解決するために、AST transformatin という機構を入れたようですが、生成規則を汚すので、SableCCの本来の美点をそこねる気がします。
JJTreeでは、BNF上で、木に組み入れる構文要素を指定できます。こっちのほうが（記述能力は低いが）汚染度は少ないですね。
これ以上詳しい話（があれば、それ）は、キマイラ・サイトのほうに載せるかもしれません。
