2

型付き式と変数アクセスを含む文法に苦労しています。このアクセスの結果タイプは、解析中に確認できず、2番目のステップで評価されます。この評価は問題ではありませんが、明確なパーサールールを作成するのは難しいようです。

異なるタイプで機能するすべての操作（比較演算子など）は、reduce/reduce競合を引き起こします。明らかに、これは、タイプが不明であるため、パーサーが「」を「 」x.a = y.bとして解析するか「」として解析するかを決定できないためです。ただし、ルールの結果タイプは特定です（常にブール値であるため）。bool_expr EUQAL bool_exprnum_expr EUQAL num_exprcomp_op

解析中にすべての型情報を破棄せず、評価フェーズで常にチェックすることなく、この問題の解決策はありますか？

短縮された文法の例を次に示します（ocamllexとocamlyaccを使用）。

comp_op:
  | bool_expr EQUAL bool_expr  { T.Equiv (T.Wrapper $1, T.Wrapper $3) }
  | num_expr EQUAL num_expr    { T.Equiv (T.Wrapper $1, T.Wrapper $3) }
  /* the wrapper type basically just wraps the expressions to get a common type */

bool_expr:
  | TRUE                       { T.Bool true }
  | FALSE                      { T.Bool false }
  | access                     { T.BoolAccess $1 }

num_expr:
  | NUMBER                     { T.Num $1 }
  | access                     { T.NumAccess $1 }

access:
  /* some more complex rules describing the access to variables */

ご協力いただきありがとうございます。

4

2 に答える 2

2

ygrekが言うように、構文解析と入力を混在させようとしないでください。式の構文カテゴリを1つだけ使用してパーサーを作成し、それを分類する別の型チェックパスを使用する方がはるかに簡単です。

理論的には、これは、タイピングルールによって行われる区別が、従来の解析テクノロジで表現できるものよりもはるかに細かいという事実に由来しています。たとえば、属性文法を使用してタイピングルールをより宣言的に指定しようとしましたが、通常のLL / LRテクノロジは確かに適切ではなく、ネストされた括弧を正規表現で解析するようなものです。

最後に、ocamlyaccの代わりにmenhirを使用する必要があります。より読みやすく表現力豊かな文法（名前付きパラメーター、パラメーター化されたルールなど）、より優れたエラー報告、および文法デバッグ機能が得られます。

于 2012-03-21T13:05:26.513 に答える
0

すでに述べたように、「タイプが正しいパーサー」を作成するのは難しいでしょう。言語によっては、これが不可能な場合もあります。

とにかく、ここでの問題は、文法が「アクセス」プロダクションのタイプを知らないということです。私が理解している限り、この生成は変数からの読み取りに似ており、そのタイプは解析時に不明です。私の見方では、100％型が正しい解析を放棄するか、変数の型を「魔法のように」知る方法を見つけます。型宣言を追跡し、レクサーに検出された変数の型を検索させることができます。次に、レクサーは変数のタイプに基づいて変数識別子トークンを送信します。

あなたの言語がどのように見えるかわからないので、このアプローチが機能するかどうかはわかりません。

于 2012-03-22T08:02:24.567 に答える