ANTLR vs. Happy與其他解析器生成器

我想在兩種語言之間編寫翻譯器，並且在互聯網上閱讀了一些內容後，我決定和ANTLR一起去。我必須從頭學習它，但除了消除左遞歸的一些麻煩之外，一切都很順利。ANTLR vs. Happy與其他解析器生成器

但是，今天有人告訴我要檢查一下基於Haskell的解析器生成器Happy。我沒有Haskell的知識，所以我可以使用一些建議，如果Happy比ANTLR好，並且值得學習。

具體而言，我所關心的是我的翻譯人員需要支持宏觀替代，我不知道ANTLR該怎麼做。也許在快樂這很容易做到？

或者如果認爲其他解析器生成器更好，我很樂意聽到它們。

來源

2009-09-01 Gabriel

如果你能說，你現在可以提供的最有用的信息是回答「什麼是源語言和目標語言？」 – 2009-09-03 03:09:52

@ 280Z28他們是內部創建的語言。它們有點類似於Java，區別在於類可以包含宏定義，然後在宏需要擴展的方法中。 – Gabriel 2009-09-04 07:04:21

同時我發現我的問題比我最初想象的要簡單。我設法在詞法分析器中與ANTLR做到這一點，所以現在不需要緊急學習快樂或其他發生器。 – Gabriel 2009-09-04 07:06:52

人們一直認爲，如果他們只是得到一個語法分析器，他們在構建語言工具時就會得到。這只是錯誤的。解析器讓你到喜馬拉雅山的然後你需要開始認真攀登。

如果您需要建築語言翻譯的工業級支持，請參閱我們的 DMS Software Reengineering Toolkit。 DMS提供

基於Unicode的詞法分析器
全上下文解析器（左遞歸？沒問題！任意超前嗎？沒問題。不明確的語法嗎？沒問題）爲C，C＃
全前端， COBOL，Java和C++，JavaScript的，... （包括完整的預處理器的C和C++）
的AST的自動構建構建符號表的任意範圍規則
ATTRIB
支持ute語法評估，以構建利用樹結構的分析器
支持控制和數據流分析（以及完整的C，Java和COBOL的實現），
源到源轉換使用源和目標語言
AST到源代碼以漂亮的方式，重現目標語言文字

關於OP的請求來處理宏：我們的C，COBOL和C++前端被處理各自的語言預處理）傳統的全面擴展方法或b）非擴展（在實際情況下）以實現解析後轉換宏的本身。雖然DMS作爲基礎並沒有專門實施宏觀處理，但它可以支持其構建和轉換。

作爲使用DMS構建的翻譯器的示例，請參閱 converting JOVIAL to C for the B-2 bomber的討論。這是100％翻譯爲> 1 MSLOC硬實時代碼。 [讓你知道我們從未被允許看到正在翻譯的實際節目（絕密）。是的，JOVIAL有一個預處理器，是的，我們將大部分JOVIAL宏轉換爲等效的C版本。

[Haskell是一個很酷的編程語言，但它本身並沒有這樣做。這不是關於語言中表達的內容。它關於計算需要什麼機器來支持操作程序的任務，而花費100人年來構建它。]

來源

2009-09-03 02:46:11

@Ira Baxter - 這是個小世界，你離我很遠。：o – 2009-09-03 03:05:24

糟糕，點擊「這是一個很棒的評論」上的「向上」按鈕。你從我的呃逆中受益。從我的用戶註冊頁面查找我的電子郵件地址並向我發送介紹性說明;在這裏可能是一些有趣的談話。 – 2009-09-03 03:36:05

這太棒了。不過，我認爲你在開源社區找不到像這樣的東西。 – Gabriel 2009-09-04 07:08:26

ANTLR vs. Happy與其他解析器生成器

回答

相關問題