ANTLR vs. Happy vs andere Parser-Generatoren

Question

Ich möchte einen Übersetzer zwischen zwei Sprachen schreiben, und nach einigem Lesen im Internet habe ich mich entschieden, mit ANTLR zu gehen. Ich musste es von Grund auf lernen, aber abgesehen von einigen Problemen mit der Beseitigung der linken Rekursion lief alles gut bis jetzt.

Allerdings sagte mir heute ein Typ, ich solle Happy, einen Haskell-basierten Parser-Generator, ausprobieren. Ich habe kein Haskell-Wissen, also könnte ich einen Ratschlag verwenden, wenn Happy tatsächlich besser ist als ANTLR und ob es sich lohnt, es zu lernen.

Konkret geht es mir darum, dass mein Übersetzer die Makrosubstitution unterstützen muss, von der ich in ANTLR noch keine Ahnung habe. Vielleicht in Happy ist das einfacher zu tun?

Oder wenn andere Parser-Generatoren noch besser sind, würde ich mich freuen, von ihnen zu hören.

Answer 1

Die Leute glauben, dass, wenn sie nur einen Parser bekommen, haben sie es beim Erstellen von Sprachwerkzeugen gemacht. Das ist einfach falsch. Parser bringen Sie zu den Ausläufern des Himalaya dann Sie müssen ernsthaft Klettern beginnen.

Wenn Sie Unterstützung für den Aufbau von Sprachübersetzern benötigen, finden Sie weitere Informationen unter DMS Software Reengineering Toolkit. DMS bietet

• Unicode-basierte lexers
• volle kontextfreie Parser (Linksrekursion? Kein Problem! Willkürliche Look-Ahead? Kein Problem. Mehrdeutige Grammatiken kein Problem)
• voller Frontends für C, C#, COBOL, Java, C++, JavaScript, ... (einschließlich dem vollständigen Preprozessoren für C und C++)
• automatische Konstruktion von Ast
• Unterstützung für den Aufbau von Symboltabellen mit beliebiger Scoping Regeln
• attrib ute Grammatik Auswertung, um Analysatoren zu bauen, die die Baumstruktur
• Unterstützung für die Kontrolle und Datenflussanalyse (sowie Realisierung von dieser für volle C, Java und COBOL),
• Source-to-Source-Transformationen mit der Syntax von die Quelle und die Zielsprache
• AST Quellcode pretty, Zielsprache Text

In Bezug auf die OP Anforderung zu reproduzieren Makros zu behandeln: unsere C, COBOL und C++ Frontends ihrer jeweiligen Sprache Vorverarbeitung durch einen Griff) die traditionelle Methode der vollständigen Expansion oder b) Nicht-Erweiterung (wo praktisch), um nach der Analyse Transfor zu ermöglichen die Makros selbst. Während DMS als Grundlage nicht spezifisch Makroverarbeitung implementiert, kann es die Konstruktion und Transformation derselben unterstützen.

Als Beispiel für einen mit DMS gebauten Übersetzer siehe die Diskussion converting JOVIAL to C for the B-2 bomber. Das ist 100% Übersetzung für> 1 MSLOC von Echtzeitcode. [Es mag Sie amüsieren, zu wissen, dass wir niemals das eigentliche Programm sehen durften, das übersetzt wird (streng geheim).]. Und ja, JOVIAL hat einen Präprozessor, und ja, wir haben die meisten JOVIAL-Makros in äquivalente C-Versionen übersetzt.

[Haskell ist eine coole Programmiersprache, aber das macht sie selbst nicht. Hier geht es nicht darum, was in der Sprache ausdrückbar ist.Es geht darum herauszufinden, welche Maschinen benötigt werden, um die Aufgabe der Manipulation von Programmen zu unterstützen, und verbringen 100 Mann-Jahre bauen es.]