現在、Pyparsing とリファレンス マニュアルの文法規則を使用して、Ada 2005 パーサーを実装しています。これは、古い Ada コードベースの一部を分析して C/C++ に変換するために必要です。
ほとんどのことが機能します。
ただし、少し面倒な問題が 1 つあります。
式などのnameスコープ付き識別子 (ルールselected_component ) を解析するときの文法規則"Global_Types.Integer2"は、左結合文法規則サイクルの一部であるため失敗します。
このルールは間違って書かれていると思います: sub-ruleは sub-ruledirect_nameの後に配置する必要がありますdirect_name。実際には、代替リストの最後に配置する必要があります。それ以外direct_nameの場合は、nameand のみに一致し"Global_Types"、その後で文字列が終了することを期待します。私が欲しいものではありません。
したがって、ルールdirect_nameを -alternatives の最後に移動しnameます...しかし、代わりに Pyparsing の無限再帰が発生し、Python が最大再帰深度を超えて吐き出します。
問題は、次のいずれかの事実によって引き起こされると思います
文法規則selected_componentの結合性はright-to-leftです。Pyparsing のリファレンス マニュアルを検索しましたが、関連するものが見つかりませんでした。ドット (
.) を右から左への結合性を持つ演算子として扱うべきですか、それとも文法規則の拡張と再構築によって解決できますか?または、Pyparsing の無限再帰にチェックがないという事実によって。これを実装するのはそれほど難しくないと思います。現在アクティブなルール (関数) からソース位置/オフセット (
getTokensEndLoc()) へのマップを使用し、現在のソース入力位置/オフセットが入力したばかりのルールに関連する位置と等しい場合、ルールは常に失敗します。
pyparsing を使用した再帰式は、私の問題に関連している可能性があります。
この問題は、残念ながらまだ回答がないPython grammar の一部を解析する際にヘルプが必要と密接に関連しているようです。
以下は、無限再帰を引き起こす Ada 2005 文法規則サイクルです。
- 名前=>
- selected_component =>
- プレフィックス=>
- 名前
この問題は Ada 固有の問題ではなく、左再帰規則を含むすべての文法に関連していることに注意してください。