Projekt zur Erstellung einer Sprachspezifikation gestartet

[TurboMagic]

Hallo Leute,

auf Github wurde kürzlich ein neues Projekt gestartet.
Ziel: Erstellen einer Sprachdefinition der Delphi Programmiersprache im Backus-Naur Format (https://de.wikipedia.org/wiki/Backus-Naur-Form).

Das Projekt ist hier: https://github.com/MHumm/DelphiGrammar

Was bringt das? Das könnte dem einen oder anderen Tool Projekt welches Code verarbeitet helfen.
Wer mithelfen will darf sich gerne melden. Voraussetzuing ist nur ein GitHub Benutzerkonto.
Ich gebe der entsprechenden Person dann Commit Rechte.
Melden, wo/wie? Naja, entweder hier oder ein issue im Projekt aufmachen.

Ja aber ist das nicht jede Menge Arbeit?
Vermutlich weniger als du denkst! Warum? Weil jemand anderes schon seine existierende BNF Fassung beigesteuert hat.
Diese ist derzeit auf Stand von Delphi 10.3.

Ach ja: bisher steht das unter der Apache 2.0 Lizenz. Falls mit der jemand Probleme haben sollte melden, dann
kann man ggf. drüber reden ob ein Lizenzwechsel sinnvoll ist.

Grüße
TurboMagic

[Rolf Frei]

Es gibt doch schon seit Jahren eine offizielle Delphi Sprachspezifikation, also wieso soll das nun geändert werden? Wenn ich das Wiki anschaue (nur kurz überflogen) graust es mich, was ich da lesen muss. Wieso um Himmelswillen sollen nun alle Bezeichner in Grossschrift geschrieben werden!?

Die Delphi Sprachspezifikation ist so wie sie ist perfekt und an die halten sich auch die meisten Entwickler. Sehe da keinen Grund wieso man da nun eine neue Spezifikation braucht. :?

[Uwe Raabe]

Zitat:

Zitat von Rolf Frei (Beitrag 1502156)

Es gibt doch schon seit Jahren eine offizielle Delphi Sprachspezifikation

Kannst du dafür mal eine Quelle nennen?

Und wenn es die schon seit Jahren gibt, wie soll die dann die neuen Sprachfeatures wie Attribute und Inline-Variablen abdecken?

[Rolf Frei]

https://www.delphipraxis.net/207753-...yle-guide.html

Oder reden wir hier von was anderem?

[dummzeuch]

Zitat:

Zitat von Rolf Frei (Beitrag 1502163)

https://www.delphipraxis.net/207753-...yle-guide.html

Oder reden wir hier von was anderem?

Das ist ein Style Guide, dabei geht es um die Formatierung des Sourcecodes. Wir reden hier aber von eine formalen Grammatik der Programmiersprache in Backus Naur Form.

Das sieht dan ungefähr so aus:

Code:

 Items inside <this> are implementation dependent
Goal -> (Program | Package | Library | Unit)
Program -> [PROGRAM Ident ['(' IdentList ')'] ';']
           ProgramBlock '.'
Unit -> UNIT QualIdent [PortabilityDirective] ';'
        InterfaceSection
        ImplementationSection
        InitSection '.'
Package -> PACKAGE Ident ';'
           [RequiresClause]
           [ContainsClause]
           END '.'
Library -> LIBRARY Ident ';'
           ProgramBlock '.'
ProgramBlock -> [UsesClause]
                [DeclSection]         
                 CompoundStmt

usw.

Quelle davon:
https://delphi.fandom.com/wiki/Object_Pascal_Grammar

[Rolf Frei]

Ok dann habe ich das falsch verstanden. Dann macht das sogar Sinn, dass es da mal eine offizielle Grammatik dazu geben könnte.

[Der schöne Günther]

Oh Gott, linkseindeutige, kontextfreie Level 2-Grammatiken in der Chomsky-Hierarchie, Pumping-Lemma, ...

Nein, das sind alles Erinnerungen die brauche ich nicht zurück.

[himitsu]

Zitat:

Zitat von TurboMagic (Beitrag 1502059)

Was bringt das? Das könnte dem einen oder anderen Tool Projekt welches Code verarbeitet helfen.

Wie wäre es, wenn man sich stattdessen an den LLVM hängt und den es parsen lässt, der schon alles weiß, und später auch das, was er jetzt noch nicht weiß?

[Sailor]

Am Wochenende habe ich mir das Projekt gedowngeloadet. Bevor nun die Meckerei losgeht: Ich finde es durchaus verdienstvoll, daß jemand aus der Gemeinde sich damit befaßt. Eigentlich ist das die Sache von Embarcadero, so etwas anzubieten, vorausgesetzt, die haben da was.
1. Es ist nicht BNF, es ist EBNF. Der Verständlichkeit ist das abträglich, besonders, wenn man es so exzessiv wie der Autor einsetzt. Aber vor allem macht EBNF es schwierig, Aktionen an die Regeln zu binden oder symbolische Baumadressen zu verwenden. BNF ist da besser geeignet.
2. Ich habe die Grammatik umgeschrieben in ein BNF-Format, das mein Generator versteht. Es gibt neben einer erklecklichen Zahl von Konflikten m.E. auf den ersten Blick einiges an Fehlern, z.B. so was wie "VAR ;". Wie stellt man sicher, daß die Grammatik die Sprache korrekt definiert? Ohne die Unterstützung von Embarcadero helfen nur umfangreiche Tests mit Code, der vom Compiler akzeptiert resp. abgewiesen wird. Jede Menge Arbeit, vermutlich mehr als du denkst!
Fazit: Gutes Vorhaben. Bis jetzt benutze ich eine Grammatik, die auf Delphi 7 beruht. Eine aktuellere wäre nicht schlecht.

[TurboMagic]

Ja, das wäre auch Sache des Herstellers, der zieht aber nur teilweise.
Soweit ich da was mitbekommen habe würde er möglicherweise eine Grammatik Korrekturlesen,
schreiben würde er keine.

Wenn in dieser Grammatik Fehler drin sind einfach kurz jeweils ein Issue dafür erstellen,
dann kann danach geschaut werden.

Ich bin jetzt auch nicht so tief in der Materie EBNF vs. BNF, ich hab' halt mal als Startpunkt
das genommen was jemand beigesteuert hat. Der hat wohl das in seinem Tool benutzt.