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

特定の文字列が固定された正式言語に属しているかどうかを判断するアルゴリズムに関する質問。

1
LL文法とLR文法の言語理論的比較
LR（k）パーサーはLL（k）パーサーよりも強力であるとよく言われます。これらの声明はほとんどの場合あいまいです。特に、固定またはすべてのkの和集合のクラスを比較する必要がありますか？では、状況はどうですか？特に、LL（*）がどのように適合するかに興味があります。kkkkkk 私の知る限り、LLパーサーとLRパーサーが受け入れるそれぞれの文法セットは直交しているため、それぞれの文法セットによって生成される言語について話しましょう。ましょによって解析することができる文法によって生成される言語のクラス示すLのR （K ）パーサ、および他のクラスの類似します。LR(k)LR(k)LR(k)LR(k)LR(k)LR(k) 次の関係に興味があります。 LL(k)⊆?LR(k)LL(k)⊆?LR(k)LL(k) \overset{?}{\subseteq} LR(k) ⋃∞i=1LL(k)⊆?⋃∞i=1LR(k)⋃i=1∞LL(k)⊆?⋃i=1∞LR(k)\bigcup_{i=1}^{\infty} LL(k) \overset{?}{\subseteq} \bigcup_{i=1}^{\infty} LR(k) ⋃∞i=1LL(k)=?LL(∗)⋃i=1∞LL(k)=?LL(∗)\bigcup_{i=1}^{\infty} LL(k) \overset{?}{=} LL(*) LL(∗)∘?⋃∞i=1LR(k)LL(∗)∘?⋃i=1∞LR(k)LL(*) \overset{?}{\circ} \bigcup_{i=1}^{\infty} LR(k) これらのいくつかはおそらく簡単です。私の目標は、「完全な」比較を収集することです。参考文献を歓迎します。
1
EPALを認識する非一般的なCFG解析アルゴリズムはありますか？
EPALはパリンドロームの言語でもあり、次の明確なコンテキストフリーの文法によって生成される言語として定義されています。 S→aaS→aaS \rightarrow a a S→bbS→bbS \rightarrow b b S→aSaS→aSaS \rightarrow a S a S→bSbS→bSbS \rightarrow b S b EPALは、多くの解析アルゴリズムの「悩みの種」です。言語を記述する文法を解析できる明確なCFGの解析アルゴリズムにはまだ出会っていません。特定のパーサーでは解析できない明確なCFGがあることを示すためによく使用されます。これは私の質問に影響を与えました： EPALで動作する明確なCFGのみを受け入れる解析アルゴリズムはありますか？ もちろん、言語を線形時間で解析するグラマー用のアドホック2パスパーサーを設計できます。EPALを念頭に置いて特別に設計されていない解析メソッドに興味があります。
3
任意の文脈自由文法の解析、ほとんどが短い断片
ユーザー定義のドメイン固有の言語を解析したい。これらの言語は通常、数学表記に近いものです（自然言語を解析していません）。ユーザーは次のようにBNF表記でDSLを定義します。 expr ::= LiteralInteger | ( expr ) | expr + expr | expr * expr 入力のようなもの1 + ( 2 * 3 )は受け入れられなければならず、入力のようなもの1 +は不正確であるとして拒否され、入力のようなもの1 + 2 * 3は曖昧なものとして拒否されなければなりません。 ここでの中心的な困難は、あいまいな文法をユーザーフレンドリーな方法で対処することです。文法を曖昧でないように制限することは選択肢ではありません。それが言語のやり方です。つまり、曖昧さを避けるために必要でない場合は、括弧を省略するほうが好ましいという考え方です。式が曖昧でない限り、解析する必要があり、そうでない場合は拒否する必要があります。 私のパーサーは、文脈に依存しない文法、あいまいなものでも動作し、すべての明確な入力を受け入れなければなりません。受け入れられたすべての入力に解析ツリーが必要です。無効またはあいまいな入力の場合、理想的には適切なエラーメッセージが必要ですが、最初に取得できるものを取り上げます。 私は通常、比較的短い入力でパーサーを呼び出しますが、入力は時々長くなります。したがって、漸近的に高速なアルゴリズムは最良の選択ではないかもしれません。入力が20シンボル未満の約80％、20〜50シンボルの19％、まれに1％のより長い入力の分布に最適化したいと思います。無効な入力の速度は大きな問題ではありません。さらに、DSLが1000〜100000入力ごとに変更されることを期待しています。数分ではなく、文法の前処理に数秒費やすことができます。 典型的な入力サイズを考慮して、どの解析アルゴリズムを調査する必要がありますか？エラー報告は私の選択の要因である必要がありますか、それとも明確な入力の解析に集中し、エラーフィードバックを提供するために完全に別個の低速なパーサーを実行する必要がありますか？ （それが必要なプロジェクト（しばらく前）では、CYKを使用しました。これは実装するのにそれほど難しくなく、入力サイズに適切に機能しましたが、非常に良いエラーを生成しませんでした。）
2
すべての「悪」正規表現に対して、悪ではない代替が存在しますか、または文法に悪魔がありますか？
どうやら、ReDos攻撃はいくつかの（そうでなければ有用な）正規表現の特性を悪用します...本質的にNFAによって定義されたグラフの可能なパスの爆発を引き起こします。 同等の「非悪」正規表現を記述することにより、このような問題を回避することは可能ですか？そうでない場合（したがって、文法はNFAによって実用的な空間/時間で処理できない）、どの構文解析アプローチがより良いでしょうか？どうして？
2
正規表現はですか？
Type 3 Grammarがある場合、プッシュダウンオートマトンで（スタックで操作を行わずに）表現できるため、コンテキストフリー言語を使用して正規表現を表現できます。しかし、解析テーブルを構築せずに、タイプ3の文法が、LL（1）、SLR（1）などであるかどうかを知ることはできますか？LR(1)LR(1)LR(1)LL(1)LL(1)LL(1)SLR(1)SLR(1)SLR(1)
1
なぜ字句解析と構文解析を分離するのですか？
ステートマシンからの単一のパスを使用してドキュメントを解析することが可能です。2つのパスを持つことの利点は何ですか？テキストをトークンに変換するレクサーと、それらのトークンの生産ルールをテストするパーサーがありますか？生産ルールをテキストに直接適用する単一のパスを用意していないのはなぜですか？
2
IELR（1）-パーサーとは何ですか？
バイソンの使い方を自分で教えようとしています。manson bison（1）はbisonについて述べています： LALR（1）、IELR（1）、または標準のLR（1）パーサーテーブルを使用して、決定性LRまたは汎用LR（GLR）パーサーを生成します。 IELRパーサーとは何ですか？World Wide Webで見つけた関連記事はすべて有料です。
1
やったときは意味を獲得するには、「左から右へのスキャン、右端の派生？」
ウィキペディアの記事によると、 L は「左から右へのスキャン」を意味し、「R」は「右端の派生」を意味します。ただし、文法に関するKnuthの元の論文では、（610ページ）を「バインドされた左から右に翻訳可能」な言語として定義しています。L R （k ）LR（k）LR(k)L R （k ）LR（k）LR(k)L R （k ）LR（k）LR(k)kkk この新しい用語は、解析の「左から右へのスキャン、左端の派生」を補完するために選択されたと推測しています。とはいえ、用語の意味がいつ変わったかはわかりません。L L （k ）LL（k）LL(k) 新しい頭字語の由来を知っている人はいますか？L R （k ）LR（k）LR(k)
3
文脈自由文法にパラメータを追加するとどうなりますか？
私は、インデンテーションに敏感な言語の文法を考えていましたが、パラメータと組み合わせた場合、CF文法がトリックを行うようです。例として、ANTLRのような形式の単純化されたPython文法の次のフラグメントを考えます。 // on top-level the statements have empty indent program : statement('')+ ; // let's consider only one compound statement and one simple statement for now statement(indent) : ifStatement(indent) | passStatement(indent) ; passStatement(indent) : indent 'pass' NEWLINE ; // statements under if must have current indent plus 4 spaces ifStatement(indent) …
5
非曖昧性は決定論とどのように違いますか？
「決定論的文脈自由文法」などの表現で「決定論的」が意味するものを理解しようとしています。（このフィールドには、より決定的な「もの」があります）。最も手の込んだ説明よりも例を挙げていただければ幸いです！可能なら。 混乱の主な原因は、文法のこの特性が（非）曖昧性とどのように異なるかを理解できないことです。 それが何を意味するかを見つけるのに最も近かったのは、D。Knuthの論文からの引用です。 、左から右への言語の翻訳に関するです： Ginsburg and Greibach（1965）は、決定論的言語の概念を定義しています。セクションVでは、これらがまさにLR（k）文法が存在する言語であることを示しています あなたがに着くとすぐに円形になります Section Vそこには、LR（k）パーサーが解析できるのは決定論的言語であると言われているからです... 以下は、「あいまいな」の意味を理解するのに役立つ例です。ご覧ください。 onewartwoearewe one war two ear eweまたはとして解析できますo new art woe are we -文法がそれを許可する場合（たとえば、私がリストしたばかりのすべての単語を持っている）。 このサンプル言語を（非）決定論的にするには、何をする必要がありますか？（たとえば、単語を削除できますo文法からをして、文法が曖昧にならないようにすることができます）。 上記の言語は決定的ですか？ PS。この例は、Godel、Esher、Bach：Eternal Golden Braidの本からのものです。 例の言語の文法を次のように定義するとしましょう。 S -> A 'we' | A 'ewe' A -> B | BA B -> 'o' | 'new' | 'art' | 'woe' …
3
バイナリデータにレクサー/パーサーを使用するのはなぜ間違っているのですか？
私はしばしばパーサーコンビネーターとは対照的にレクサー / パーサーで作業し、解析でクラスを取ったことがない人を見て、バイナリデータの解析について尋ねます。通常、データはバイナリであるだけでなく、コンテキスト依存でもあります。これは基本的に、1種類のトークン（バイト用トークン）のみを持つことになります。 レクサー/パーサーによるバイナリデータの解析が、解析クラスを受講していないが、理論に基づいたCS学生にとって十分に明確である理由を誰かが説明できますか？
2
演算子の左関連付けを維持しながら、文法の左再帰を削除する
この演習に問題があります： λ計算の次のあいまいな文法をGとします。 E → v | λv.E | EE | (E) ここで、Eは単一の非終端記号、λv.EはEの変数vに関する抽象化を表し、EEはアプリケーションを表します。 L（G '）= L（G）となるようなLL（1）文法G'を定義し、次の通常の規則を課すことでGのあいまいさを解決します。 抽象化は正しい連想です。 アプリケーションは関連付けられたままです。 アプリケーションは、抽象化よりも優先されます。 G 'のLL（1）解析テーブルと、文字列の解析時に取得された解析ツリーを表示しますλv1. λv2. v1v2v1。 あいまいさの設定の優先順位と関連付けを排除し、次の文法を取得しました。 E -> EF | F F -> λv.G | G G -> (E) | v これはLL（1）ではありません。これは、生成E -> EFが再帰的に行われるためです。しかし、私が得るその生産から左再帰を排除します： E -> FE¹ E¹-> FE¹ | ɛ F -> …
2
LL（k）とLR（k）の文法を区別する方法はありますか？
私は最近、コンパイラの設計について勉強しています。LL文法とLR文法の2種類の文法について知りました。 また、すべてのLL文法がLRであり、LL文法がLR文法の適切なサブセットであるという事実も知っています。1つ目はトップダウン解析で使用され、2つ目はボトムアップ解析で使用されます。 しかし、特定の文法がLLまたはLRであると言えるようにする方法はありますか？
2
正規表現の言語は、それを解析するためにプッシュダウンオートマトンを必要としますか？
ユーザーが入力した正規表現をNFAに変換して、マッチングのために文字列に対してNFAを実行できるようにします。正規表現の解析に使用できる最小マシンは何ですか？ 括弧の意味はカウントの必要性を意味し、DFA / NFAは任意のカウントを実行できないため、プッシュダウンオートマトンである必要があると思います。この仮定は正しいですか？たとえば、式a（bc *）dはPDAを必要とするため、括弧内の部分式が正しく処理されます。
3
この文法LL（1）はどうですか？
これはドラゴンブックからの質問です。これは文法です： S→AaAb∣BbBaS→AaAb∣BbBaS \to AaAb \mid BbBa A→εA→εA \to \varepsilon B→εB→εB \to \varepsilon 質問では、それがLL（1）であってSLR（1）ではないことをどのように示すかを尋ねます。 それがLL（1）であることを証明するために、構文解析テーブルを作成してみましたが、セル内で複数のプロダクションを取得していますが、これは矛盾しています。 このLL（1）の状態と、それを証明する方法を教えてください。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.