何年も離れてからレクサーとパーサーに戻ると、コンテキストの目的で、状態変更の概念に困惑していることに気づきます。私はレモンをパーサーとして使用し、独自のレクサーをまとめています。
次のような入力例を見てみましょう。
[groups]
syscon:
0x000 sysmemremap
0x004 presetctrl
[registers]
sysmemremap:
map 1-0
rsvd 31-2
presetctrl:32
mux 2-0
..etc...
したがって、「syscon:」と「sysmemremap:」は同じように見えますが、一方は GROUPNAME で、もう一方は REGISTERNAME です。[グループ] と [レジスタ] の間には、各トークンが実際に何であるかを決定するコンテキストの変更があります。
その文脈上の変更を行うのに最適な位置にあるのはパーサーですか? パーサーにはセクション文法がなく、あるセットの文法はあるセットの状況に適用され、別のセットの文法は別のセットに適用されるため、モードがそうすべきです。
編集:ウィキペディアで問題を要約した「レクサーハック」のエントリを見つけました:
コンテキストを追加しないと、レクサーは型識別子を他の識別子と区別できません。これは、すべての識別子が同じ形式であるためです。.... 一般に、解決策はセマンティック シンボル テーブルからレクサーに情報を戻すことで構成されます。つまり、レクサーからパーサーへの純粋な一方向のパイプラインとして機能するのではなく、セマンティック分析からレクサーに戻るバックチャネルがあります。
パーサーのトークンの事前読み取りについて何を推測できますか? パーサーが先に進み、より良い一致を行うためにより多くのトークンを読み取っている場合 (少なくともある程度はそうなると思います)、パーサーの状態変更がレクサーにとって遅すぎるという状況に陥る可能性があります。それはすでにそのトークンに会って処理しました!
それとも私はこれを考えすぎていますか？