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.

[Sailor]

Gibt es Näheres zu dem Autor? Hat der eventuell Kontakt zu Embarcadero? Wie gesagt, der Löwenanteil der Arbeit ist die Validierung der Grammatik. Zumindest die Quellen der VCL müßten akzeptiert werden. Ich sitze zur Zeit gerade an einer Parsersuite, in Delphi geschrieben. Da brauche ich sicher noch 2 oder 3 Wochen. Vielleicht setze ich mich danach mal an die Grammatik. Strittige Auslegungen lassen sich wahrscheinlich mit der aktuellen Version von Delphi beantworten. Zumindest den kontextfreien Teil sollte man hinkriegen. Für die Toolentwicklung könnte das eventuell erstmal ausreichen.

[TurboMagic]

Zum Thema Validierung: wenn's dann mal soweit ist hab' ich Kontakte zu EMBT
und wir können dann versuchen da eine Validierung hinzubekommen.

Ich würde mich jedenfalls freuen, wenn du demnächst mal drüber schaust.
Du kannst Änderungen entweder als Pull Request einreichen oder wenn du willst
und deinen GitHub Benutzernamen angibst kannst du auch direkt Commit Rechte bekommen.

[Sailor]

Wenn ich mit den aktuellen Sachen durch bin, setze ich mich dran, wenn nichts dazwischen kommt. Eventuell kann ich die Delphi7-Grammatik als Basis nehmen. So Ende Februar wird das klar sein.

[Sailor]

Es hat denn doch länger gedauert als gedacht, aber sei's drum.
Ich habe die Grammatik von EBNF in BNF-Form gebracht, zum einen, weil mein Generator nur BNF versteht, zum anderen, weil das den Anschluß der Funktionen erheblich erleichtert, die die kontext-abhängige Syntax überprüfen sollen. Dabei habe ich mir die Freiheit genommen, Konstruktionen wie "VAR ;" oder "CONST ;" zu entfernen. Möglicherweise hat der Autor eine Obermenge von Delphi definiert, kann sein, daß das für die Entwicklung von Tools besser ist. Er verwendet aber auch Dinge wie "[ ',' <ConstExpr> ]*" neben "( <ConstantDecl> ';' )*". Letzteres steht allgemein für "Kann fehlen oder beliebig oft vorkommen", während die Konstruktion in eckigen Klammern "Einmal oder keinmal" bedeutet und so eigentlich keinen Unterschied bringt. Mir erscheint das suspekt.
Von 968 Zuständen weisen 62 Konflikte auf, 80 Shift-Reduce- und 34 Reduce-Reduce-Konflikte. Mit dem größten Teil der Shift-Reduce-Konflikte kann man wahrscheinlich leben. Auf die Reduce-Reduce-Konflikte trifft das nicht zu, die ändern die Sprache zu sehr.
Fazit: Ich bezweifele, daß die Grammatik als Ausgangspunkt für die Definition einer ordentlichen Sprachreferenz geeignet ist. Jedenfalls ist das nicht ohne sehr viel Arbeit zu schaffen. Erschwerend kommt hinzu, daß auch die Sprachbeschreibung in der Hilfe auf subtile Fragen kaum Antworten hat. Das läßt sich nur durch intensives Testen klären, was einen immensen Aufwand bedeutet. Und niemand garantiert, daß im nächsten Release das alles noch so ist. Beispiele für solche kleinen Änderungen, die einen ratlos werden lassen, findet man auch hier in der Praxis.
Ich zitiere Dich mal: "Ja aber ist das nicht jede Menge Arbeit? Vermutlich weniger als du denkst! ". Nope, es ist viel mehr, als man denkt, leider.
Ich hänge mal die transformierte Grammatik dran, zur gefälligen Selbstbedienung. Selbstverständlich kann ich bei diesem Rewrite Fehler reingebracht haben, mea culpa, also bitte konstruktiv meckern.