我不知道C#和Java語法是否是LALR(x)?如果是的話,x的價值是什麼?C#和Java語法LALR(x)?
編輯:
接受真正的答案之後,我覺得這是更好地更改Q這樣:
是否有任何LALR(x)的解析,可以解析Java的當前版本(版本7)或C#(版本4)?如果是的話,x的價值是什麼?
我不知道C#和Java語法是否是LALR(x)?如果是的話,x的價值是什麼?C#和Java語法LALR(x)?
編輯:
接受真正的答案之後,我覺得這是更好地更改Q這樣:
是否有任何LALR(x)的解析,可以解析Java的當前版本(版本7)或C#(版本4)?如果是的話,x的價值是什麼?
如果沒有首先爲語言指定特定的語法,您就不能問這個問題,因爲有些語法可能是,有些則可能不是。
也許你的意思是最近Java規範中發佈的Java語法。你的意思是Java 7嗎?我不確定你可以爲C#指定一個特定的語法,至少不是來自Microsoft的一個,尤其是C#4.0;我不相信他們已經發表了語法。
我可以告訴你,我不認爲C#可以是LALR(x),因爲它有一些看起來像標識符的元素,但可以是某些上下文中的關鍵字。這要求詞法分析器知道解析器期望決定一個類似標識符的標記是關鍵字,還是標識符。因此,必須從解析器向詞法分析器提供反饋,否則詞法分析器必須生成這兩個令牌並將它們傳遞給解析器以決定它想要的內容。 LALR解析器在標記流上定義,沒有任何反饋,並且每個輸入標記只有一個解釋。
我不認爲Java是Java 1.5或更高版本,當枚舉被引入作爲一個特殊的類型與自己的關鍵字。這是因爲,對於Java 1.5編譯器來處理使用枚舉作爲變量名的現有Java 1.4程序,枚舉必須在某些情況下作爲關鍵字處理,並在其他情況下作爲變量名處理。所以Java 1.5解析器與C#有相同的問題。作爲一個實際問題,LALR(1)[第一版Java可能是一個例外]沒有真正的語言,任何構建真正解析器的人(特別是LALR)都必須採取某種方法來解決這個問題。(海灣合作委員會着名地用LALR解析器解析了C++,並且長時間使用可怕的符號表破解,所以它可以區分作爲變量的標識符和作爲typedef實例的標識符之間的區別,現在它有一些手工實現遞歸下降解析器,但我認爲糟糕的破解仍然存在)。所以我不確定你的問題的答案的價值。
我們的C# 4.0 and Java 7 members of our family of language front ends都使用GLR解析器解析語言,擴展了兩者的反饋能力以及處理同一標記的兩種解釋的能力。 GLR提出了LALR(x)的疑問,而反饋和多重解釋讓我們可以處理許多不屬於純GLR能力的語言。
編輯:經過一番思考,可能會有一個真正醜陋的方式,使兩個語法處理他們的上下文中的關鍵字。我們以Java的枚舉爲例。有現實必須是語法規則:
type = 'enum' '{' enum_members '}' ;
但我們還需要允許'枚舉'作爲一個identifer。我們可以這樣做,通過與非末端取代終端令牌 標識符:
identifier = IDENTIFIER | 'enum' ;
並堅持標識符由詞法分析器產生的終端。現在至少詞法分析器不必決定如何處理enum;解析器的確如此。但是你的指定語法將不得不像這樣塑造,以便有機會成爲LALR(x)。
我們的解析器用於執行此操作以允許某些關鍵字有時用作標識符。我們如前所述改變了我們的解析引擎,不要再這樣做了。
至少爲Java(版本1.0),它是:http://java.sun.com/docs/books/jls/first_edition/html/19.doc.html
「第一版」?我們可以使用java 7. –
Java的語法(1.0版本)已知是LALR(1); this site提供了一種語法,並且以通知開始
語法已經過機械檢查以確保它是LALR(1)。
我不知道C#是LALR(1),但有可用的C# parser written in bison
這裏,這表明它可能是LALR(1)(假設你允許優先級聲明)。
對於它的價值,通常LALR(1)是唯一使用的LALR解析器。如果您需要爲語法使用類似LALR(2)的東西,那麼使用帶明確優先消除歧義的LALR(1)解析器或更強大的解析器(如GLR解析器)通常會更好。
希望這會有所幫助!
謝謝,但我認爲所引用的文檔屬於Java的早期版本。你確定新的Java語言規範(包括泛型等)仍然是LALR(1)嗎? – hsalimi
C#中添加了C#語法的語法。 –
「The C#spec」?你的意思是ECMA規範?那不是C#4.0,MS也沒有實現該規範。 –
我看到幾個建議來關閉這個問題。我無法理解推理;這個問題很清楚。 –