簡體   English   中英

為什么選擇二元運算符而不是一元運算符?

[英]Why is a binary operator selected over a unary operator?

對於既是一元又是二元的運算符,為什么在a@b這樣的表達式中選擇二元運算符?

經過大量的思考和搜索,我仍然無法回答為什么像a+b這樣的東西被解析為二進制表達式而不是a(+b) ,這顯然是胡言亂語。

我不認為上下文無關語法能夠區分這兩者,並且試圖在這個版本的標准中找到答案並沒有給我任何答案。

解析器是否專門選擇二進制版本,因為一元版本會亂碼? 如果是這樣,標准中是否有一個部分對此進行了概述?

上下文無關並不意味着“沒有狀態”。 解析器有很多 state 來跟蹤給定到目前為止看到的標記可能出現的語法規則,並預測接下來會出現哪些標記。 因為沒有規則說兩個表達式可以直接相鄰出現,所以它甚至永遠不會認為a+b可以是表達式a+b並排。

例如,假設我們正在使用這個基本語法:

expr → expr '+' unary_expr | unary_expr
unary_expr → '+' unary_expr | IDENT

(符號: 給出了非終結符可以擴展的規則, |表示替代的可能性。 '+'是加號標記, IDENT是任何標識符標記。)

讓我們解析a+b 我們的解析器的起始 state 將是:

1. expr → expr '+' unary_expr
         ^
2. expr → unary_expr
         ^
3. unary_expr → '+' unary_expr
               ^
4. unary_expr → IDENT
               ^

有它在一開始就考慮的規則。 它不知道會得到哪個,可能是其中任何一個。 請注意,它正在考慮的每個產品還包括一個cursor ,我在上面用^符號標記了它。 這就是解析器在規則中的位置。

好的,現在它看到了第一個IDENT令牌。 它將其 state 更新為以下內容:

1. expr → expr '+' unary_expr
              ^
2. expr → unary_expr
                    ^
3. unary_expr → IDENT
                     ^

現在它正在考慮三個規則。 請注意,cursor 在它們中的每一個中都向右移動。

如果第一條規則是正確的,那么它剛剛看到了一個表達式,並期待下一個'+' 或者,也許第二條規則是正確的,而a只是一元表達式。 在這種情況下,它預計不會有更多的令牌跟隨。 解析器不知道它會是哪個,所以它正在考慮兩者。

您會看到,如果下一個標記是'+'那么它必須是二進制加號。 為什么? 因為第一條規則是唯一預期下一個'+'標記的規則。

要將'+'解釋為一元加,解析器必須在其活動的 state 中包含此規則,在'+'之前使用 cursor:

unary_expr → '+' unary_expr 
            ^

你可以看到它沒有。


如果上下文無關並不意味着無狀態,那么它是什么意思呢? 我們從什么“背景”中“自由”?

上下文無關是對語法可以包含哪些規則的限制。 相反的是context-sensitive ,其中產品可以根據周圍環境而變化。 上下文相關語法比上下文無關語法更強大,但它們更難解析——即使對人類來說也是如此。 語言理論家很早就發現,上下文無關語法占據了一個甜蜜點,即足夠強大,可以表達而不會過於復雜而無法推理。

有關更多詳細信息,請參閱: 上下文無關語法與上下文相關語法?

上下文無關文法(CFG) 是一種文法,其中(如您所述)每個產生式的形式為 A → w,其中 A 是非終結符,w 是終結符和非終結符的字符串。 非正式地,CFG 是一種語法,其中任何非終結符都可以在任何時候擴展到其任何產生式。 文法的語言是可以從開始符號派生的終結符串的集合。

上下文相關文法(CSG) 是一種文法,其中每個產生式的形式為 wAx → wyx,其中 w 和 x 是終結符和非終結符字符串,y 也是終結符字符串。 換句話說,產生式給出的規則是“如果你在給定的上下文中看到 A,你可以用字符串 y 替換 A”。 不幸的是,這些語法被稱為“上下文敏感語法”,因為這意味着“上下文無關”和“上下文敏感”不是對立的,這意味着某些語法類別可以說需要大量上下文信息被考慮在內,但不被正式認為是上下文相關的。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM