3

「reportAttemptingFullContext」と「reportContextSensitivity」を理解するのに問題があり、文法で論文を回避するのに問題があります。ここに例があります：

IF L_COUNT > 0 THEN
    LINEFEED;
END IF;

ここに私の文法の抜粋があります：

if_statement
:   
IF plsql_condition THEN 
seq_of_statements? elsif_statement* else_statement? END IF
;

plsql_condition
    :   expr_bool
    ;

expr_bool
:
expr_or (OR expr_or)*
;

expr_or
:
expr_and (AND expr_and)*
;

expr_and
:
NOT? expr_not
;

expr_not
:
expr_not_is |
expr_not_between |
expr_not_in |
expr_not_op |
expr_add
;

そしてエラーメッセージ：

line 1:13 TIME: 2013-02-12 09:15:52.225, reportAttemptingFullContext d=116, rule='expr_not', input='L_COUNT > 0'
line 1:11 TIME: 2013-02-12 09:15:52.228,reportContextSensitivity d=116, rule='expr_not', input='L_COUNT >'
line 1:11 TIME: 2013-02-12 09:15:52.354, reportAttemptingFullContext d=120, rule='expr_not_op', input='>'
line 1:11 TIME: 2013-02-12 09:15:52.355,reportContextSensitivity d=120, rule='expr_not_op', input='>'

文法は全体的にかなり大きいです。これは簡単な例です。基本的に、代替手段があるたびに問題が発生します（上記の「expr_not」のように）。これらを回避するにはどうすればよいですか？セマンティック述語を使用してみましたが、これは (私の知る限り) コード生成時にルール内のトークンの位置が固定されている場合にのみ可能です。次のコードでコメントする場合 (より複雑な例):

COLUMN FORMAT FORMAT.PRICE(OBJ_CURRY(TOP.STRIKE_CURRY_ID).RD(TOP.INTR_PAY * (TOP.NOTE_RATIO * L_ALLOC)),TOP.STRIKE_CURRY_ID);

解析時間を 20 倍します。これはかなり痛いです。この場合も、「reportAttemptingFullContext」を取得します。

私の質問: 代替手段で「reportAttemptingFullContext」を回避するにはどうすればよいですか。

ご協力ありがとうございました。敬具、ヴォルフガング・ハマー

4

1 に答える 1

2

完全なコンテキスト解析の唯一の問題は、潜在的なパフォーマンスへの影響です (必要な頻度と、SLL 競合を解決するために必要な先読みに応じて異なります)。あなたの文法が SLL モードで明確である場合、ANTLR ブックに記述されている 2 段階の解析戦略 (ここでは 1 つの実装を使用) は、構文エラーを含まないすべてのソース ファイルの完全なコンテキスト解析を防ぎます。2 段階の構文解析では、常にフル コンテキストを有効にした構文解析と同じ最終結果が生成されますが、次のプロパティを満たす文法と入力のパフォーマンスが大幅に向上します。

  1. 解析されるソース ファイルの大部分には、構文エラーは含まれていません。
  2. 構文エラーを含まないソース ファイルの大部分は、 and に対して同じ解析ツリーを提供PredictionMode.SLLしますPredictionMode.LL(PredictionMode列挙を参照)。
于 2013-02-12T15:32:16.440 に答える