タグ付けされた質問 「parsers」

DFAと実行時に入力された単語のLevenshtein Automataを実行して、あいまいな解析を実行する方法があります（タイプミスがある場合でも文字列を受け入れます）。Earleyパーサーでも同様のことができますか？アルゴリズムを理解するのは難しいと思います。この質問に答えることは言うまでもありません。

10 algorithms  context-free  finite-automata  parsers  string-metrics 

LR（0）パーサーでは、各状態はLR（0）アイテムのコレクションで構成されます。LR（0）アイテムは、位置で注釈が付けられたプロダクションです。LR（1）パーサーでは、各状態はLR（1）アイテムのコレクションで構成されます。これは、位置と先読み文字で注釈が付けられたプロダクションです。 LR（1）オートマトンの状態が与えられると、各LR（1）アイテムから先読みトークンを削除することによって形成される構成セットは、LR（0）オートマトンのいくつかの状態に対応する構成セットを生成することが知られています。その意味で、LR（1）オートマトンとLR（0）オートマトンの主な違いは、LR（1）オートマトンにはLR（0）オートマトンの状態のコピーが多く、それぞれに先読みが付いていることです。情報。このため、特定のCFGのLR（1）オートマトンは、通常、そのCFGの対応するLR（0）パーサーよりも大きくなります。 私の質問は、LR（1）オートマトンをどれだけ大きくできるかです。ある場合は文法のアルファベットの明確な終端記号は、その後、原則的に、我々は、少なくとも一回のサブセットあたりLR（0）オートマトンの各状態を複製する必要があるかもしれません 1（LRにつながる潜在的に、明確な終端記号）オリジナルのLR（0）オートマトンより倍大きいオートマトン。LR（0）オートマトンの個々のアイテムがそれぞれ異なるLR（0）アイテムのセットで構成されている場合、さらに大きなブローアップが得られる可能性があります。n 2 nんnnんnn2ん2n2^n とはいえ、LR（1）オートマトンが対応するLR（0）オートマトンより大幅に大きい文法のファミリーを構築する方法を見つけることができないようです。私が試したすべてのことで、サイズはわずかに大きくなりました（通常は2〜4倍程度）が、大きな爆発につながるパターンを見つけることができないようです。 LR（1）オートマトンが対応するLR（0）オートマトンより指数関数的に大きい、文脈自由文法の既知のファミリーはありますか？それとも、最悪の場合、実際には指数関数的な爆発が起こらないことがわかっていますか？ ありがとう！

10 context-free  parsers  lr-k 

缶誰かが私に制作しようとバックトラックと理由を再帰下降構文解析啓発とS → A（この順番では）文法によって形成された言語認識していないS → A S Aを| A。S→aSaS→aSaS \rightarrow aSaS→aaS→aaS \rightarrow aaS→aSa | aaS→aSa | aaS \rightarrow aSa\ |\ aa 言語からの単語を解析するだけのようです。{a2n | n≥1}{a2n | n≥1}\{a^{2^n}\ |\ n \ge 1 \} たとえば、このABNFパーサージェネレーターをプロダクションルールとともに使用して、そのようなパーサーを生成しましたがS = "a" S "a" / "aa"、パーサーはを認識しませんaaaaaa。 パースツリーの左端からのノードの連結が7で始まるまでは、プロダクションを使用し、その後、ツリーが見えるまでプロダクションS → a aを選択して、パースツリーを上に移動することを期待します。このような：S→aSaS→aSaS \rightarrow aSaaS→aaS→aaS \rightarrow aa S / | \ a …

10 context-free  formal-grammars  compilers  parsers 

以下の文脈自由文法のプレゼント「ぶら下がりelse」タイプのあいまいさ（と想像を意味し、の略と命令またはブロックのいくつかの他の種類の略）： たとえば、はまたはとして解析できます（これは、この文法の最も単純/最短のあいまいな単語です）。b c Saaaif expr thenbbbelseccc aacbc（a（acbc））（a（ac）bc）S→aSbS|aS|cS→aSbS|aS|c \begin{aligned} S &\rightarrow aSbS \;|\; aS \;|\; c\\ \end{aligned} aacbcaacbcaacbc(a(acbc))(a(acbc))(a(acbc))(a(ac)bc)(a(ac)bc)(a(ac)bc) この「ぶら下がりelse」曖昧軍「他」（解決するために、「標準」方法「IF-THEN」（最も近い/最も内側とペアに）ステートメントを）。これは次のようにして実現できます。 この文法は明確です。上記の例では、解析をます。a Sbbbaaa（a（acbc））ST→aTbS|aS|c→aTbT|cS→aTbS|aS|cT→aTbT|c \begin{aligned} S &\rightarrow aTbS \;|\; aS \;|\; c\\ T &\rightarrow aTbT \;|\; c\\ \end{aligned} (a(acbc))(a(acbc))(a(acbc)) 質問：aacbcの解析を強制するあいまいさを解決する別の自然な方法はありますか？言い換えると、私は上記の2つと同じ言語を生成する、明確で、aacbcを（a（ac）bc）として解析する文法を探しています。a a c b c a a c b c （a （a c ）b c …

9 context-free  formal-grammars  parsers  ambiguity 

Earleyベクトルを認識エンジンとして使用するのは非常に簡単です。文字列の最後に達したとき、位置0で開始された公理生成が完了したかどうかを確認するだけです。少なくとも1つある場合、文字列は受け入れられます。 Earleyベクトルを使用して解析ツリーを再構築することは、それほど明白ではありません。実際、私はアルゴリズムの手順がどのように機能するかを理解することはできません。さらに、私が見つけた唯一の参照はあいまいまたは超技術的なものでした。誰かがそれに光を当てることができますか？

9 context-free  dynamic-programming  parsers  ambiguity  syntax-trees 

大学では、一般的な計算理論とチューリングマシンについてより具体的に学びました。優れた理論上の結果の1つは、潜在的に大きなアルファベット（記号）を犠牲にして、状態の数を2つまで減らすことができるということです。 私はさまざまなチューリングマシンの例を探していましたが、提示された一般的な例は括弧カッチャー/チェッカーです。基本的に、括弧などの文字列(()()()))()()()がバランスしているかどうかをチェックします（前の例では、バランスが取れていない場合は0を返します）。 私がこれを3つの状態のマシンにしかできない場合があるので、試してください。私は誰かがこれを理論上の最小値の2に減らすことができるかどうか、そして彼らのアプローチ/状態/シンボルが何であったかを知りたいです！ 明確にするために、括弧は空白のテープの間に「挟まれている」ため、上記の例 - - - - - - - (()()()))()()() - - - - - - -ではテープ上の入力になります。アルファベットが含まれるであろう(、)、1、0、-、および*halt*状態が状態としてカウントされません。 参考までに、私が持っている3つの状態のアプローチは次のとおりです。状態の説明： State s1: Looks for Closing parenthesis State s2: Looks for Open parenthesis State s3: Checks the tape to ensure everything is matched Symbols: ),(,X 次のようにリストされた遷移： Action: State Symbol NewState WriteSymbol …

9 turing-machines  context-free  parsers 

この文法は再帰的に残されています： Expression ::= AdditionExpression AdditionExpression ::= MultiplicationExpression | AdditionExpression '+' MultiplicationExpression | AdditionExpression '-' MultiplicationExpression MultiplicationExpression ::= Term | MultiplicationExpression '*' Term | MultiplicationExpression '/' Term Term ::= Number | '(' AdditionExpression ')' Number ::= [+-]?[0-9]+(\.[0-9]+)? したがって、理論的には、再帰的降下は機能しません。ただし、各左再帰ルールが特定の優先レベルに対応し、単一のトークンの先読みで正しい生成を選択するのに十分であるという文法のプロパティを利用することで、左再帰ルールをwhileループで個別に解析できます。 たとえば、AdditionExpression非終端を解析するには、次の疑似コードで十分です。 function parse_addition_expression() { num = parse_multiplication_expression() while (has_token()) { get_token() if (current_token …

8 reference-request  formal-grammars  recursion  parsers  left-recursion 

私はCスタイル言語のパーサーに取り組んでおり、そのパーサーにはCスタイルの/ ** /コメントに一致する正規表現が必要です。今、私はこの表現をウェブ上で見つけました： /\*([^\*]*\*+[^\*/])*([^\*]*\*+|[^\*]*\*/ しかし、ご覧のとおり、これはやや乱雑な表現であり、実際に一致させたいかどうかが正確に一致するかどうかはわかりません。 それらが本当に正しいことを手動で簡単に確認でき、その後上記の正規表現に変換可能（「コンパイル可能」）な正規表現を（厳密に）定義する別の方法はありますか？

8 compilers  parsers  regular-languages 

左再帰と左分解の両方を含むプロダクションを持つ文法がある場合 F→ FB a ∣ c D S∣ cF→FBa|cDS|c\qquad \displaystyle F \to FBa \mid cDS \mid c 左再帰または左因数分解のどちらが優先されますか？

8 formal-languages  formal-grammars  parsers  left-recursion 

問題の抽象的な説明 私の見たところ、解析解除とは、ASTからトークンストリームを作成することを意味し、再度解析すると、等しいASTが生成される、つまりparse(unparse(AST)) = AST保持されるはずです。 これは、同じASTを生成する有効な解析ツリーを見つけることと同じです。 言語は、eBNFバリアントを使用した、コンテキストフリーのS属性の文法で記述されます。 したがって、アンパーサーは、すべての文法制約が保持されている通過ノードを通過する有効な「パス」を見つける必要があります。これは基本的に、文法生成規則へのASTノードの有効な割り当てを見つけることを意味します。これは一般に制約充足問題（CSP）であり、バックトラックすることにより、解析と同様に解決できます。O （eん）O（eん）O(e^n) 幸いなことに、構文解析では、GLRを使用してでこれを行うことができます（またはより適切に文法を制限します）。AST構造は文法生成規則構造に非常に近いので、実行時間が解析よりも悪い実装を見て本当に驚きました。XTextは解析にANTLRを使用し、解析解除にバックトラックを使用しています。O （ん３）O（ん３）O(n^3) ご質問 コンテキストフリーのS属性文法は、パーサーとアンパーサーが共有する必要があるすべてのものですか、それとも、たとえば、解析手法/パーサーの実装に制約がありますか？ この問題は一般的にではないと感じています-天才がこれを手伝ってくれるでしょうか？O （eん）O（eん）O(e^n) StackOverflowでこの質問に対する回答を受け取りませんでした。ここで質問することを提案されましたが、私は冗長性が嫌いなので、ここで回答するように頼むことを許してくれるといいのですが。

7 algorithms  compilers  parsers  attribute-grammars 

Pascalの文法を書く必要がありますが、問題を引き起こしていることが1つだけあります。 演算子があるとしましょう（優先度の低いものから高いものに並べ替えられます）。 Postfix^。 接頭辞^。 [ ]、及び.、（同じ優先順位と左連想）。 唯一の終端はid小文字であるです。 次に、式が次のとおりだとします。 任意のID。 Postfix^演算子を使用した式。 プレフィックス^演算子を含む任意の式。 が.後に続く任意の式id。 とを含む任意の式[および]。 次に、shift-reduceとreduce-reduceの競合なしにLALR文法を作成する方法、またはそれができない場合は、それができないことをどのように証明できるかを知りたいです。 いくつかの例： good: a.b.c.d a.b^.c ^a.b^ a.b^^[c]^^.d.e ^^a.b^.d.e^[] bad: a.^b.c 接頭辞がなければ^、この問題は簡単に解決できますが、接頭辞の記号が原因で問題が解決しません。誰か助けてもらえますか？これまでの私の解決策： // this works without the prefix but it does not produce a.b^.c which is wrong. A ::= B | A ^ ; B ::= C | …

7 programming-languages  parsers  formal-grammars