2017-05-08 15 views
0

私は現在、言語を解析するのにhappyを使用していますが、パーサーがLALRパーサーであると言う以外はパーサーとは関係ありません。文法の抜粋は次のとおりです。かっこと異なるタイプの式の解析

ArithExpr -> ArithExpr + ArithExpr 
ArithExpr -> (ArithExpr) 
ArithExpr -> ... 

BoolExpr -> ArithExpr == ArithExpr 
BoolExpr -> (BoolExpr) 
BoolExpr -> ... 

問題は、私はreduce-reduce競合を起こしていることです。

((2 + 3) == (4 + 5)) 

あり、この式を解析する唯一の方法だが、問題は私もパーサはいくつかの問題を抱えて起動する最初のかっこで考えている:私は、次のようなものを解析しようとすると問題が発生すると思います。私はこれが当てはまると思う理由は、パーサーが将来ArithExprBoolExprかどうかを知りませんし、先読みのトークンが1つしかないので、間違っているかもしれない任意の選択をしなければなりません。

この言語を受け入れるように文法を書き直してもらえますか?または、私は実際にはArithExprBoolExprの両方を1つのユニフォームとして解釈し、タイプチェック中に実際のタイプを扱うべきですか?

答えて

1

Exprを解析し、意味解析中にタイプチェックを行うだけです。さもなければ、カッコで囲まれた式(あなたは遅すぎるまでのタイプを知ることはできません)またはファーストクラスのブール値(変数はブール値を持つ可能性がありますか?

代替手段についてはmy answer hereを参照してください(しかし、同じアドバイスを与えることになります)。私はその答えに記載されているテクニックの価値を本当に確信していないため、完全性のためのリンクを提供していますが、それは本質的に異なるLALRパーサジェネレータの場合と同じ問題だと思います。

関連する問題