規則與替代方法 - 如何避免reportAttemptingFullContext和reportContextSensitivity

我有一些麻煩理解'reportAttemptingFullContext'和'reportContextSensitivity'，並在我的語法避免這些問題的一些麻煩。下面一個例子：規則與替代方法 - 如何避免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'。

謝謝你的幫助。親切的問候，WolfgangHämmer

來源

2013-02-12 wolfgang hämmer

完整的上下文解析唯一的問題是潛在的性能影響（取決於需要多長時間一次以及需要多少前瞻來解決SLL衝突）。如果您的語法在SLL模式下是明確的，那麼ANTLR書中描述的兩階段解析策略（使用one implementation here）將阻止對不包含語法錯誤的所有源文件進行全環境解析。兩階段解析總是會產生與啓用了全部上下文的解析相同的最終結果，但對符合以下屬性的語法+輸入會獲得主要的性能優勢。

大部分被解析的源文件都不包含語法錯誤。
大多數不包含語法錯誤的源文件爲PredictionMode.SLL和PredictionMode.LL提供了相同的分析樹（請參閱PredictionMode枚舉）。

來源

2013-02-12 15:32:16

規則與替代方法 - 如何避免reportAttemptingFullContext和reportContextSensitivity

回答

相關問題