Hi Johannes,
Am 22.09.19 um 17:23 schrieb Johannes Bauer:
Ich bin bisher mit Ragel wirklich voll und ganz zufrieden und kann
wissen, was andere so verwenden. Dass das in so eine "angeregte
Hi Johannes,
Am 22.09.19 um 17:23 schrieb Johannes Bauer:
Ich bin bisher mit Ragel wirklich voll und ganz zufrieden und kann
wissen, was andere so verwenden. Dass das in so eine "angeregte
Ich warte ja auf das Gegenbeispiel, also: deinen C-Parser.
finden im Standard-Dokument unter "Annex A" sowie in Fragmenten in den einzelnen Kapiteln. Sie ist halt nur nicht LL(1).
zahlst du beim Debuggen drauf. Wo muss ich jetzt die Aktionen platzieren? Wie bekomme ich das Speicherleck-frei? Wie bekomme ich
geparsed. Mit einem generierten Parser muss man damit durch ein paar Ebenen Generat (yacc, lex) durch und dabei Annahmen treffen, wie der generierte Code sich benimmt.
Stefan
lange nicht, dass einen Parser mit Generator schreiben leicht ist.
Du kannst offenbar keine Standards lesen. Denn da steht ganz klar zuerstmal: Annex A (informative) -- muss ich dir jetzt den Unterschied
to be an aid to comprehension. It is not an exact statement of the language."
genau das habe ich geschrieben, keine ausdefinierte Grammatik).
Puh, naja, das ist jetzt Aussage gegen Aussage. Du findest das Schreiben
Das ist wohl richtig, eine ordentliche Grammatik zu schreiben ist auch
elendige Arbeit.
Einen Tod muss man sterben. Vermutlich ist dann wohl ausschlaggebend, womit man am meisten Erfahrung hat.
Johannes
-- selben Hardware." -- Hans-Peter Diettrich in d.s.e.
yacc ist nicht einfach. Wer gackert muss auch legen.
Das ist die Zusammenfassung der Fragmente. Nicht normativ, weil die normativen Teile nebst der semantischen Bedingungen in den anderen Kapiteln stehen, und weil dir niemand zusichert, in dem Anhang nichts vergessen zu haben.
Analyse" nicht sauber trennt. Jedem Praktiker ist das egal. Regeln wie "maximum munch" (also dass 'inti' ein Wort ist und nicht das gleiche wie 'int i') werden quasi immer in Prosa angegeben, nicht in der Grammatik.
Stefan
lediglich STARTET.
Ich bin mir extrem sicher, dass ich ein Programm hinkriege, dass nicht
Und einen Parser kann man auch in einer Programmiersprache schreiben,
Performance nicht kritisch ist.
Joa und ich habe produktiven, sicherheitskritsichen Kernelcode geschrieben, der jahrelang unterbrechungsfrei laufen muss. Da kann man sich keine Ressourcenleaks erlauben, nicht mal die Kleinsten.
Na du musst dich schon entscheiden. Entweder du unterstellst mir
bekommst eine entsprechend unfreundliche Antwort. Beides geht nicht.
Mag ja sein, trotzdem hast du einen INFORMATIVEN Teil als "Beleg"
ganz klar drin steht, dass es eben nicht den Sprachumfang abdeckt.
beliebiges Beispiel raus: "14.2. Names of template specializations". Eine popelige Grammatik, evtl 15 Zeilen lang. Gefolgt von 1 1/2 Seiten Prosa, die dann genau sagt wie die zu interpretieren ist.
Das ist keine formale Beschreibung einer Sprache. Das ist Prosa.
Eine formale Beschreibung, die man im idealfall direkt einem Parser vorlegen kann, also maschinenlesbar ist. C++ ist aber als Sprache so kompliziert, dass ich vermute, dass das wohl nicht (mehr?) machbar ist. Deswegen nutzt man eben viel Prosa und Beispiele, um zu verdeutlichen, was gemeint ist.
komplizierten Disambiguation Regeln. Die wirklich korrekt zu implementieren ist (auch aufgrund der mangelhaften Definition als
wieder bei Beispielen, die von einem Compiler gefressen werden und von einem anderen nicht.
gehabt mir trivialsten Mist wie
std::vector
std::vector
nur gruselig.
Johannes
-- selben Hardware." -- Hans-Peter Diettrich in d.s.e.
Am 27.09.2019 um 10:37 schrieb Johannes Bauer:
Das nennt sich - ich wiederhole mich - semantische Bedingungen. Von
usw.).
Diese Disambiguierungsregeln hat es zum Teil von C geerbt. 'a * b;' ist ein expression-statement oder eine Deklaration.
Das hat nichts mit schwammiger Disambiguierung zu tun, das ist ein ganz normaler "maximum munch" Lexer, der, wenn man ihm keinen Tipp gibt, '>>' als ein Token parsed.
Solche Effekte gibt es in vielen Sprachen. Pascal:
a := sqrt(.5);
(parsed nicht, weil '(.' als '[' interpretiert wird.)
Stefan
Am 27.09.2019 um 17:42 schrieb Stefan Reuther:
dabei sind, das "dangling else" wird auch weit einfacher in der
hat, nicht aber "short short". Ist eigentlich heutzutage auch "long
Sofern man Digraphen als Option eingeschaltet hat. Heutige Compiler
per Default. Delphi unterscheidet inzwischen sogar Kommentare in { } und
Schreibweise auskommentieren.
DoDi
Am 27.09.2019 um 21:22 schrieb Hans-Peter Diettrich:
"long signed long" ist das gleiche wie "long long".
24-Bit-Typen kennt (MPLAB C18). Was sollte denn "short short" sein? Beiselten in freier Natur anzutreffen sein. Einfach, weil sich der
Zumindest die Turbo-Pascal-Compiler hatten keine mir bekannte
Das wiederum hatte Turbo Pascal auch.
Stefan
nutzloser ist die reine formale Grammatik. Weil dann kann ich
PROGRAM := chr(0..255)*
Ist aber halt super nutzlos, so eine Grammatik.
Schon klar. Aber es geht nicht darum, wieso der Parser das so parst, sondern was per Definition die *korrekte* Art des Parsens ist. Und, wenn
std::vector
Formal gesehen vor C++x ein Syntaxfehler. Ich glaube mich daran zu errinern, dass sowohl der MS C++-Compiler als auch der icc trotzdem das geparst haben, was "gemeint" war, und nur der gcc sich daran verschluckte. Und meiner Errinerung nach war gcc eben formal "korrekt". Aber das ist alles jetzt schon ewig her, bin mir in den Details nicht mehr ganz sicher.
Das verdeutlicht aber genau das Problem, das ich anspreche: Jemand, der einen Compiler schreibt, versucht das "richtige" zu machen, weil die
Schwanz mit dem Hund.
Johannes
-- selben Hardware." -- Hans-Peter Diettrich in d.s.e.
Am 28.09.2019 um 11:58 schrieb Stefan Reuther:
Das hat dann aber nichts mit einem C Standard zu tun, sondern ist eine compilerspezifische Erweiterung.
Deshalb schrieb ich ja "heutige" Compiler :-]
DoDi
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.