Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #264203 > unrolled thread

State Machine Compiler für 8-bit AVRs?

Back to article view | Back to de.sci.electronics

Contents

  State Machine Compiler für 8-bit AVRs? Andreas Weber <info@tech-chat.de> - 2019-09-21 11:29 +0200
    Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-21 12:26 +0200
      Re: State Machine Compiler für 8-bit AVRs? Andreas Weber <info@tech-chat.de> - 2019-09-21 19:09 +0200
        Re: State Machine Compiler für 8-bit AVRs? Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-09-21 20:37 +0200
          Re: State Machine Compiler für 8-bit AVRs? Andreas Weber <info@tech-chat.de> - 2019-09-22 12:48 +0200
            Re: State Machine Compiler für 8-bit AVRs? olaf <olaf@criseis.ruhr.de> - 2019-09-22 13:27 +0200
            Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-22 17:23 +0200
              Re: State Machine Compiler für 8-bit AVRs? Andreas Weber <info@tech-chat.de> - 2019-09-23 20:15 +0200
        Re: State Machine Compiler für 8-bit AVRs? Stefan Reuther <stefan.news@arcor.de> - 2019-09-22 10:48 +0200
        Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-22 12:55 +0200
          Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-22 17:32 +0200
            Re: State Machine Compiler für 8-bit AVRs? Gerhard Hoffmann <dk4xp@arcor.de> - 2019-09-22 20:43 +0200
              Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-22 21:10 +0200
            Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-23 00:34 +0200
              Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-23 09:12 +0200
                Re: State Machine Compiler für 8-bit AVRs? Gerhard Hoffmann <dk4xp@arcor.de> - 2019-09-23 14:15 +0200
                  Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-23 14:31 +0200
                    Re: State Machine Compiler für 8-bit AVRs? Stefan Reuther <stefan.news@arcor.de> - 2019-09-24 19:18 +0200
                      Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-24 20:47 +0200
                        Re: State Machine Compiler für 8-bit AVRs? Stefan Reuther <stefan.news@arcor.de> - 2019-09-25 17:51 +0200
                          Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-27 10:37 +0200
                            Re: State Machine Compiler für 8-bit AVRs? Stefan Reuther <stefan.news@arcor.de> - 2019-09-27 17:42 +0200
                              Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-27 21:22 +0200
                                Re: State Machine Compiler für 8-bit AVRs? Stefan Reuther <stefan.news@arcor.de> - 2019-09-28 11:58 +0200
                                  Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-28 13:48 +0200
                              Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-28 13:43 +0200
                  Re: State Machine Compiler für 8-bit AVRs? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-23 19:07 +0200
                    Re: State Machine Compiler für 8-bit AVRs? Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-23 20:08 +0200
    Re: State Machine Compiler für 8-bit AVRs? Gerhard Hoffmann <dk4xp@arcor.de> - 2019-09-22 13:40 +0200
      Re: State Machine Compiler für 8-bit AVRs? olaf <olaf@criseis.ruhr.de> - 2019-09-22 14:59 +0200

Page 1 of 2  [1] 2  Next page →

#264203 — State Machine Compiler für 8-bit AVRs?

Hallo an alle,

ich verwende seit knapp 4 Jahren immer wieder den Ragel [1] Generator
für Parser auf Atmel/Microchip AVRs z.B. für UART Empfangsroutinen.

Was verwendet ihr so, sobald die Grammatik etwas komplizierter wird? Lex
wäre ja auch eine Möglichkeit.

TIA, Gruß Andy

[1] https://www.colm.net/open-source/ragel/

[toc] | [next] | [standalone]

#264204

Am 21.09.2019 um 11:29 schrieb Andreas Weber:
> Hallo an alle,
>
> ich verwende seit knapp 4 Jahren immer wieder den Ragel [1] Generator
> für Parser auf Atmel/Microchip AVRs z.B. für UART Empfangsroutinen.
>
> Was verwendet ihr so, sobald die Grammatik etwas komplizierter wird? Lex
> wäre ja auch eine Möglichkeit.

Meine Lexer und Parser habe ich bisher immer selbst geschrieben, das ist 
IMO kein Hexenwerk. C verfügt ja bereits über Konvertierungsroutinen, 
und wenn sich beide Seiten an diese halten, und sinnvolle Trennzeichen 
zwischen zwei Werten und Records einstreuen, wo sollten dann Probleme 
herkommen?

DoDi

[toc] | [prev] | [next] | [standalone]

#264229

Am 21.09.19 um 12:26 schrieb Hans-Peter Diettrich:
> Meine Lexer und Parser habe ich bisher immer selbst geschrieben, das ist
> IMO kein Hexenwerk.

Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.

> und wenn sich beide Seiten an diese halten, und sinnvolle Trennzeichen
> zwischen zwei Werten und Records einstreuen,

Dazu müsste man beide Seiten selbst in der Hand haben. Sobald du an ein
bestehendes Protokoll ran musst, kann man sich das nicht mehr aussuchen.

-- Andy

[toc] | [prev] | [next] | [standalone]

#264231

Am 21.09.19 um 19:09 schrieb Andreas Weber:

> Am 21.09.19 um 12:26 schrieb Hans-Peter Diettrich:
>> Meine Lexer und Parser habe ich bisher immer selbst geschrieben, das ist
>> IMO kein Hexenwerk.
> 
> Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.

Eine komplizierte Grammatik ist in jedem Fall kompliziert, egal welche 
Werkzeuge man nutzt.

Wenn man das Prinzip verstanden hat, ist der Aufwand, um eine formal 
korrekte Definition für einen Parser-Generator zu schreiben oder den 
Parser gleich selbst zu schreiben, nicht sooo unterschiedlich.
Das gilt umso mehr dann, wenn der vom Generator erzeugte Codestil nicht 
recht in die verwendete Umgebung passt und man auch noch eine 
Interface-Schicht bauen müsste.

Hergen

[toc] | [prev] | [next] | [standalone]

#264261

Hallo Hergen,

Am 21.09.19 um 20:37 schrieb Hergen Lehmann:
> Am 21.09.19 um 19:09 schrieb Andreas Weber:
> 
>> Am 21.09.19 um 12:26 schrieb Hans-Peter Diettrich:
>>> Meine Lexer und Parser habe ich bisher immer selbst geschrieben, das ist
>>> IMO kein Hexenwerk.
>>
>> Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.
> 
> Eine komplizierte Grammatik ist in jedem Fall kompliziert, egal welche
> Werkzeuge man nutzt.

Warum versuchen mich hier Leute davon zu überzeugen KEIN Werkzeug dafür
einzusetzen?

Das fühlt sich für mich an als ob mir jemand erklärt:
"Verwende doch Assembler, mach BRAUCHT keinen C Compiler. Das geht auch
alles so. Die libc braucht man nicht, kann man auch in Assembler
machen." Ich hoffe wir müssen an dieser Stelle nun keine Diskussion
führen, warum man heute eben nicht mehr Assembler schreiben sollte ohne
einen wirklich, wirklich guten Grund.

> Wenn man das Prinzip verstanden hat, ist der Aufwand, um eine formal
> korrekte Definition für einen Parser-Generator zu schreiben oder den
> Parser gleich selbst zu schreiben, nicht sooo unterschiedlich.

Ich habe über 10 Jahre die Parser selbst geschrieben. Mit Ragel kann ich
mir den Zustandsautomaten visualisieren lassen (graphviz dot) was die
Entwicklung deutlich vereinfacht und gleich noch als Dokumentation
taugt. Die Lesbarkeit und damit die Wartbarkeit für andere ist IMHO auch
deutlich höher.

> Das gilt umso mehr dann, wenn der vom Generator erzeugte Codestil nicht
> recht in die verwendete Umgebung passt und man auch noch eine
> Interface-Schicht bauen müsste.

Klar. In dem von mir angesprochenen Fall integriert sich das aber super
in avr-gcc und AVR libc.


Ich fühle mich an die Diskussion mit Studenten erinnert, dass man
git/mercurial/subversion gar nicht braucht, weil man ja die Order
einfach wegkopieren und umbenennen kann.

Danke für deine Meinung, Gruß Andy

[toc] | [prev] | [next] | [standalone]

#264263

Andreas Weber <info@tech-chat.de> wrote:


 >Warum versuchen mich hier Leute davon zu überzeugen KEIN Werkzeug dafür
 >einzusetzen?

Vermutlich weil es denen zu komplex ist. :-)

Ich hab fuer solche Anwendungen auf Microcontrollern auch schon flex
genutzt und wuerde es jederzeit wieder machen. 

Vorteile:
	Sehr flexibel, es ist eine kleinigkeit da mal eben einen
	neues Kommando hinzuzufuegen.

	Weil die nutzung so einfach ist, wenn man einmal damit umgehen kann,
	nutzt man es auch fuer Kleinigkeiten (z.B Debuginterface) wo man sonst
	eher denken wuerde: "Och, noe, dafuer bin ich jetzt zu faul"

Nachteile: Erzeugt ziemlich grossen C-Source. Das bekommt man von
	   Hand bestimmt effizienter hin. Allerdings ist das bei den
	   fetten Flash heutiger Controller kein Problem. 

 >taugt. Die Lesbarkeit und damit die Wartbarkeit für andere ist IMHO auch
 >deutlich höher.

Nicht zwangslaeufig weil die sich ja auch mit dem verwendeten
Generator auskennen muessen und ihn auch haben muessen.


Olaf

[toc] | [prev] | [next] | [standalone]

#264277

On 22.09.19 12:48, Andreas Weber wrote:

>>> Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.
>>
>> Eine komplizierte Grammatik ist in jedem Fall kompliziert, egal welche
>> Werkzeuge man nutzt.
> 
> Warum versuchen mich hier Leute davon zu überzeugen KEIN Werkzeug dafür
> einzusetzen?

Kann ich dir nicht beantworten.

Was genau stört dich denn an der Ragel-Syntax bzw. was für Features
hättest du gerne, die im Moment fehlen? Kannst du eventuell eine
Beispielgrammatik teilen um zu illustrieren, wie du es im Moment (als
Workaround) löst und was du gerne hättest?

Eventuell kommen dann bessere Tipps.
Viele Grüße,
Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264345

Hi Johannes,

Am 22.09.19 um 17:23 schrieb Johannes Bauer:
> On 22.09.19 12:48, Andreas Weber wrote:
> 
>>>> Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.
>>>
>>> Eine komplizierte Grammatik ist in jedem Fall kompliziert, egal welche
>>> Werkzeuge man nutzt.
>>
>> Warum versuchen mich hier Leute davon zu überzeugen KEIN Werkzeug dafür
>> einzusetzen?
> 
> Kann ich dir nicht beantworten.
> 
> Was genau stört dich denn an der Ragel-Syntax bzw. was für Features
> hättest du gerne, die im Moment fehlen?

Ich bin bisher mit Ragel wirklich voll und ganz zufrieden und kann
bisher alles damit abbilden was ich möchte. Wollte eigentlich nur
wissen, was andere so verwenden. Dass das in so eine "angeregte
Diskussion" ausufert, hätte ich nicht gedacht.

Danke, Gruß Andy

[toc] | [prev] | [next] | [standalone]

#264250

Am 21.09.2019 um 19:09 schrieb Andreas Weber:
> Am 21.09.19 um 12:26 schrieb Hans-Peter Diettrich:
>> Meine Lexer und Parser habe ich bisher immer selbst geschrieben, das ist
>> IMO kein Hexenwerk.
> 
> Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.

Auch bei komplexeren Grammatiken ist das kein Hexenwerk.

Je nach dem, was für ein Protokoll das ist, will man da auch sowas wie
Fehlerbehandlung haben. Wenn also irgendwo ein Trennzeichen verschluckt
wird, soll der Parser sich davon erholen können und nicht nur "parse
error" sagen und bis zum nächsten Powercycle bockig sein. Das in einer
Grammatik auszudrücken ist zwar möglich, aber umständlich. Mit einem
eigenen Parser hat man da durchaus einfachere Möglichkeiten (und sei es
sowas wie "mit dem eigenen Parser die Paketierung zerlegen, und die
Paket-Payloads dann mit was generiertem").


  Stefan

[toc] | [prev] | [next] | [standalone]

#264262

Am 21.09.2019 um 19:09 schrieb Andreas Weber:
> Am 21.09.19 um 12:26 schrieb Hans-Peter Diettrich:
>> Meine Lexer und Parser habe ich bisher immer selbst geschrieben, das ist
>> IMO kein Hexenwerk.
>
> Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.

Wäre C kompliziert genug?

Anscheinend werden nur LL(1) Grammatiken akzeptiert, und für die läßt 
sich ein Lexer von Hand leicht erzeugen. Bei wirklich komplizierten 
Grammatiken sind ggf. Umformungen notwendig, die nur jemand durchführen 
kann, der sich mit Grammatiken so gut auskennt daß er weiß, wie ein 
Parser funktioniert und ihn entsprechend auch selbst schreiben kann.

DoDi

[toc] | [prev] | [next] | [standalone]

#264280

On 22.09.19 12:55, Hans-Peter Diettrich wrote:
> Am 21.09.2019 um 19:09 schrieb Andreas Weber:
>> Am 21.09.19 um 12:26 schrieb Hans-Peter Diettrich:
>>> Meine Lexer und Parser habe ich bisher immer selbst geschrieben, das ist
>>> IMO kein Hexenwerk.
>>
>> Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.
> 
> Wäre C kompliziert genug?

Wenn *das* stimmen würde, dann würde ich das gerne mal sehen. Denn eine
vollständige, fehlerfreie C-Grammatik "von Hand" zu schreiben, ohne
Werkzeugunterstützung, halte ich für so gut wie unmöglich. Insofern,
wenn du das wirklich gemacht hast, würde ich das gerne von dir lernen.
Deine Chance, dein Können unter Beweis zu stellen.

Meine persönliche Vermutung, die sich mit deinen bisherigen Äußerungen
allerdings viel besser deckt, ist, dass das lediglich pures Geschwätz
ist. Vermutlich hast du einen Parser für urgendein Subset von C
geschrieben, der bei jeder minimalen Deviation im Codestil schon
krachend auseinanderfällt.

> Anscheinend werden nur LL(1) Grammatiken akzeptiert, [...]

C ist defintiv kein LL(1), das weißt du ja sicherlich.

Gruß,
Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264293

Am 22.09.19 um 17:32 schrieb Johannes Bauer:
> On 22.09.19 12:55, Hans-Peter Diettrich wrote:
>> Am 21.09.2019 um 19:09 schrieb Andreas Weber:
>>> Am 21.09.19 um 12:26 schrieb Hans-Peter Diettrich:
>>>> Meine Lexer und Parser habe ich bisher immer selbst geschrieben, das ist
>>>> IMO kein Hexenwerk.
>>>
>>> Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.
>>
>> Wäre C kompliziert genug?
> 
> Wenn *das* stimmen würde, dann würde ich das gerne mal sehen. Denn eine
> vollständige, fehlerfreie C-Grammatik "von Hand" zu schreiben, ohne
> Werkzeugunterstützung, halte ich für so gut wie unmöglich. Insofern,
> wenn du das wirklich gemacht hast, würde ich das gerne von dir lernen.
> Deine Chance, dein Können unter Beweis zu stellen.
> 
> Meine persönliche Vermutung, die sich mit deinen bisherigen Äußerungen
> allerdings viel besser deckt, ist, dass das lediglich pures Geschwätz
> ist. Vermutlich hast du einen Parser für urgendein Subset von C
> geschrieben, der bei jeder minimalen Deviation im Codestil schon
> krachend auseinanderfällt.
> 
>> Anscheinend werden nur LL(1) Grammatiken akzeptiert, [...]
> 
> C ist defintiv kein LL(1), das weißt du ja sicherlich.
> 
> Gruß,
> Johannes

Pascal-Compiler waren schon immer mit rekursivem Abstieg, und
sogar der gcc war nur bis Version 3 yacc/bison-basiert und hat
jetzt einen handgeschnitzten Parser.

Wenn's praktisch alle so machen, dann muss es wohl möglich sein;
das mit dem leeren Geschwätz ist also ein Bumerang.

Dass man für ernsthafte Sprachen die Symboltabelle massieren muss,
ist unschön, aber wirklich context-frei ist in der Praxis wenig.

Was ist  foo *bar?  Eine Variablen-Deklaration? Eine Multiplikation?

Ausführliche Diskussion in :

< 
https://stackoverflow.com/questions/6319086/are-gcc-and-clang-parsers-really-handwritten 
    >


Gruß, Gerhard

[toc] | [prev] | [next] | [standalone]

#264294

On 22.09.19 20:43, Gerhard Hoffmann wrote:

> Pascal-Compiler waren schon immer mit rekursivem Abstieg, und
> sogar der gcc war nur bis Version 3 yacc/bison-basiert und hat
> jetzt einen handgeschnitzten Parser.

Weil sie den C und C++ gemerged haben. Und C++ /hat/ keine
wohldefinierte Grammatik mehr. Ist also wirklich schwierig, dafür einen
Parser zu schreiben. Das sind unter anderem, nur für den Parser, etwa
41000 Zeilen Code, mehr als ein Megabyte Quellcode. Das ist also etwas,
das nicht mal eben so hinzuschreiben ist.

> Wenn's praktisch alle so machen, dann muss es wohl möglich sein;
> das mit dem leeren Geschwätz ist also ein Bumerang.

Insofern stehe ich zu meiner Aussage und widerspreche, dass es
"praktische alle" eben mit handgeschnitzten Parsern machen. Im
Gegenteil, wenn du mal suchst:

https://github.com/SilverScar/C-Language-Parser
Ist Lex/Yacc-basiert

https://github.com/eliben/pycparser
Nutzt ply

https://github.com/praeclarum/CLanguage
Nutzt jay

https://github.com/awi29/C-parser
Nutzt Lex/Yacc

https://github.com/vickenty/lang-c
Nutzt rustpeg

Die Wenigsten schreiben also einen Lexer/Parser "von Hand". Noch
weniger, wenn es keinen triftigen Grund dafür gibt (bei GCC ist
wiegesagt C++ der Grund).

> Dass man für ernsthafte Sprachen die Symboltabelle massieren muss,
> ist unschön, aber wirklich context-frei ist in der Praxis wenig.
> 
> Was ist  foo *bar?  Eine Variablen-Deklaration? Eine Multiplikation?

Ich habe ja schon geschrieben, C ist kein LL(1). Keine mir bekannte
(nicht-esoterische) Programmiersprache ist LL(1), so nebenbei.

Gruß,
Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264298

Am 22.09.2019 um 17:32 schrieb Johannes Bauer:
> On 22.09.19 12:55, Hans-Peter Diettrich wrote:
>> Am 21.09.2019 um 19:09 schrieb Andreas Weber:
>>> Am 21.09.19 um 12:26 schrieb Hans-Peter Diettrich:
>>>> Meine Lexer und Parser habe ich bisher immer selbst geschrieben, das ist
>>>> IMO kein Hexenwerk.
>>>
>>> Dann hast du bis jetzt vielleicht keine komplizierte Grammatik gehabt.
>>
>> Wäre C kompliziert genug?
>
> Wenn *das* stimmen würde, dann würde ich das gerne mal sehen. Denn eine
> vollständige, fehlerfreie C-Grammatik "von Hand" zu schreiben, ohne
> Werkzeugunterstützung, halte ich für so gut wie unmöglich. Insofern,
> wenn du das wirklich gemacht hast, würde ich das gerne von dir lernen.

Deinem Geschwätz nach kommen mir Zweifel an Deiner Lernfähigkeit :-(

> Deine Chance, dein Können unter Beweis zu stellen.

Hatte ich seinerzeit als "ToPas" bei SourceForge reingestellt.

> Meine persönliche Vermutung, die sich mit deinen bisherigen Äußerungen
> allerdings viel besser deckt, ist, dass das lediglich pures Geschwätz
> ist.

Dein Vermutungslevel ist als unbrauchbar notiert. Vielleicht informierst 
Du Dich mal über den VisualBasic Discompiler zur Justierung Deiner Meinung.

> Vermutlich hast du einen Parser für urgendein Subset von C
> geschrieben, der bei jeder minimalen Deviation im Codestil schon
> krachend auseinanderfällt.

Auch hier ist das Gegenteil der Fall. Mein Parser hat aufgedeckt, daß 
Microsofts Header zu Visual C nicht standardardkonform sind, ein 
Workaround wurde eingebaut. Dazu noch ein paar Erweiterungen für gcc.

>> Anscheinend werden nur LL(1) Grammatiken akzeptiert, [...]
>
> C ist defintiv kein LL(1), das weißt du ja sicherlich.

Bis auf 1 Ausnahme ist C98 erstaunlicherweise LL(1), insgesamt also 
LL(2). Das Fehlen einer offiziellen LL-Grammatik sagt ja definitiv 
nichts über eine Sprache aus :-]

DoDi

[toc] | [prev] | [next] | [standalone]

#264306

On 23.09.19 00:34, Hans-Peter Diettrich wrote:

>> Deine Chance, dein Können unter Beweis zu stellen.
> 
> Hatte ich seinerzeit als "ToPas" bei SourceForge reingestellt.

Sehr gut. Endlich lieferst du mal was. Ich habe mal meine VM angeworfen
und dein Meisterwerk getestet:

https://imgur.com/a/McpnjZb

Schon beim einfachen Gerumklicken fliegen einem "Access Violations" nur
so um die Ohren, dass es kracht! Das fand ich MEGA witzig, weil du ja,
in deiner ach so oberlehrerhaften Art, ja kürzlich erst von Korrektheit
von Programmen geschwafelt hast und Pascal über C erhoben. Genau die
Bugs, die du angeblich durch Pascal vermeidest hast du offenbar so
dutzendfach in deinem Programmchen drin, dass es UNBENUTZBAR wird. Sehr
hübsche Demonstration, den Screenshot sollte man sich einrahmen.

Danach nochmal neugestartet, nichtdeterminsitisch fliegt einem eine
Access Violation schon beim BLOSSEN START des Programms um die Ohren.
Gacker! Ist das eine neue Form nichtdeterministischer Programmierung?
Wow, ich bin echt beeindruckt.

Aber zum Kernstück. Deinem Parser, der ja, wir errinern uns an meine
ursprüngliche Aussage:

>eine vollständige, fehlerfreie C-Grammatik "von Hand" zu schreiben,
>ohne Werkzeugunterstützung, halte ich für so gut wie unmöglich

Keywords für dich, DoDi, zum mitschreiben:
  - vollständig
  - fehlerfrei

Okay, okay, das ist also die Messlatte. Siebenzeiler in C:

int foo(int y, ...) {
  int *x[12];
  x[3] = x[9];
  x[10] = *(&(*(x + 3)));
  "foo";
  return 0;
}

Einfach, oder? Das ist korrektes C. Na dann!

*TOMMELWIRBEL*

error translation_unit

<loriot>Ach!</loriot>

Wer hätte das gedacht, DoDi? Dass es richtig schwer ist, eine
fehlerfreie Grammatik hinzukriegen? Danke, dass du das schön bewiesen hast.

Das ist genau der Grund, warum man Parser Generatoren erfunden hat, weil
es Leute gibt, denen aufgefallen ist, dass einem Menschen halt
Cornercases oft durch die Lappen gehen. So wie dir.

>> Meine persönliche Vermutung, die sich mit deinen bisherigen Äußerungen
>> allerdings viel besser deckt, ist, dass das lediglich pures Geschwätz
>> ist.
> 
> Dein Vermutungslevel ist als unbrauchbar notiert. 

Bestätigt, wolltest du schreiben. Siehe oben.

> Vielleicht informierst
> Du Dich mal über den VisualBasic Discompiler zur Justierung Deiner Meinung.

Ja sorry aber "VisualBasic Discompiler" ist offenbar so ein
unbrauchbarer Suchbegriff, dass Google gleich sagt: "Showing results for
Visual Basic Decompiler"

Ich habe also keine Ahnung, worauf du hinaus willst. Du aber offenbar
auch nicht, sondern willst ja wohl nur von deinem Turbofail ablenken.

>> Vermutlich hast du einen Parser für urgendein Subset von C
>> geschrieben, der bei jeder minimalen Deviation im Codestil schon
>> krachend auseinanderfällt.
> 
> Auch hier ist das Gegenteil der Fall.

Ähm, kracht bei einem Siebenzeiler auseinander. Hat micht genau FÜNF
Minuten gebraucht, den Testcase zu finden. Ich habe mehr Zeit damit
verbracht, die Screenshots im Gimp zu editieren, als damit, dir
Stümperei nachzuweisen.

> Mein Parser hat aufgedeckt, daß

...das händische Schreiben korrekter, vollständiger Parser richtig
schwer ist.

>> C ist defintiv kein LL(1), das weißt du ja sicherlich.
> 
> Bis auf 1 Ausnahme ist C98 erstaunlicherweise LL(1),

C ist also kein LL(1), richtig.

Immerhin, muss man dir zu Gute halten, hast du ausnahmsweise was
geliefert, statt immer nur heiße Luft zu produzieren. Auch wenn es jetzt
halt nicht dein Argument gestärkt hat, sondern exakt das Gegenteil bewiesen.

Gruß,
Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264325

Am 23.09.19 um 09:12 schrieb Johannes Bauer:
> On 23.09.19 00:34, Hans-Peter Diettrich wrote:
> 
>>> Deine Chance, dein Können unter Beweis zu stellen.
>>
>> Hatte ich seinerzeit als "ToPas" bei SourceForge reingestellt.
> 
> Sehr gut. Endlich lieferst du mal was. Ich habe mal meine VM angeworfen
> und dein Meisterwerk getestet:
> 
> https://imgur.com/a/McpnjZb
> 
> Schon beim einfachen Gerumklicken fliegen einem "Access Violations" nur
> so um die Ohren, dass es kracht! Das fand ich MEGA witzig, weil du ja,
> in deiner ach so oberlehrerhaften Art, ja kürzlich erst von Korrektheit
> von Programmen geschwafelt hast und Pascal über C erhoben. Genau die
> Bugs, die du angeblich durch Pascal vermeidest hast du offenbar so
> dutzendfach in deinem Programmchen drin, dass es UNBENUTZBAR wird. Sehr
> hübsche Demonstration, den Screenshot sollte man sich einrahmen.
> 
> Danach nochmal neugestartet, nichtdeterminsitisch fliegt einem eine
> Access Violation schon beim BLOSSEN START des Programms um die Ohren.
> Gacker! Ist das eine neue Form nichtdeterministischer Programmierung?
> Wow, ich bin echt beeindruckt.
> 
> Aber zum Kernstück. Deinem Parser, der ja, wir errinern uns an meine
> ursprüngliche Aussage:
> 
>> eine vollständige, fehlerfreie C-Grammatik "von Hand" zu schreiben,
>> ohne Werkzeugunterstützung, halte ich für so gut wie unmöglich
> 
> Keywords für dich, DoDi, zum mitschreiben:
>    - vollständig
>    - fehlerfrei
> 
> Okay, okay, das ist also die Messlatte. Siebenzeiler in C:
> 
> int foo(int y, ...) {
>    int *x[12];
>    x[3] = x[9];
>    x[10] = *(&(*(x + 3)));
>    "foo";
>    return 0;
> }
> 
> Einfach, oder? Das ist korrektes C. Na dann!
> 
> *TOMMELWIRBEL*
> 
> error translation_unit
> 
> <loriot>Ach!</loriot>
> 
> Wer hätte das gedacht, DoDi? Dass es richtig schwer ist, eine
> fehlerfreie Grammatik hinzukriegen? Danke, dass du das schön bewiesen hast.
> 
> Das ist genau der Grund, warum man Parser Generatoren erfunden hat, weil
> es Leute gibt, denen aufgefallen ist, dass einem Menschen halt
> Cornercases oft durch die Lappen gehen. So wie dir.
> 
>>> Meine persönliche Vermutung, die sich mit deinen bisherigen Äußerungen
>>> allerdings viel besser deckt, ist, dass das lediglich pures Geschwätz
>>> ist.
>>
>> Dein Vermutungslevel ist als unbrauchbar notiert.
> 
> Bestätigt, wolltest du schreiben. Siehe oben.
> 
>> Vielleicht informierst
>> Du Dich mal über den VisualBasic Discompiler zur Justierung Deiner Meinung.
> 
> Ja sorry aber "VisualBasic Discompiler" ist offenbar so ein
> unbrauchbarer Suchbegriff, dass Google gleich sagt: "Showing results for
> Visual Basic Decompiler"
> 
> Ich habe also keine Ahnung, worauf du hinaus willst. Du aber offenbar
> auch nicht, sondern willst ja wohl nur von deinem Turbofail ablenken.
> 
>>> Vermutlich hast du einen Parser für urgendein Subset von C
>>> geschrieben, der bei jeder minimalen Deviation im Codestil schon
>>> krachend auseinanderfällt.
>>
>> Auch hier ist das Gegenteil der Fall.
> 
> Ähm, kracht bei einem Siebenzeiler auseinander. Hat micht genau FÜNF
> Minuten gebraucht, den Testcase zu finden. Ich habe mehr Zeit damit
> verbracht, die Screenshots im Gimp zu editieren, als damit, dir
> Stümperei nachzuweisen.
> 
>> Mein Parser hat aufgedeckt, daß
> 
> ...das händische Schreiben korrekter, vollständiger Parser richtig
> schwer ist.
> 
>>> C ist defintiv kein LL(1), das weißt du ja sicherlich.
>>
>> Bis auf 1 Ausnahme ist C98 erstaunlicherweise LL(1),
> 
> C ist also kein LL(1), richtig.
> 
> Immerhin, muss man dir zu Gute halten, hast du ausnahmsweise was
> geliefert, statt immer nur heiße Luft zu produzieren. Auch wenn es jetzt
> halt nicht dein Argument gestärkt hat, sondern exakt das Gegenteil bewiesen.

Wenn hier einer den Oberlehrer macht, dann du.
Und er muss dir auch nichts liefern, du hast nichts bei ihm gekauft.


 > *TOMMELWIRBEL*

Wirklich bewiesen hast du garnix. Du hast ein paar Exotencompiler
aufgezählt die einen Parsergenerator benutzen, aber die wichtigen
Compiler, die jeder hernimmt, wie gcc oder clang benutzen rekursiven
Abstieg. Und der gcc frisst dein Beispiel in einer halben Millisekunde,
problemlos, bis auf ein paar Bemerkungen, dass das Beispiel nix
Sinnvolles macht.

Pascal nimmt auch rekursiven Abstieg. Und da sind Bösartigkeiten
wie das with-statement drinnen:

with record_variablenliste do begin ... end

und zwischen begin & end sind die Komponenten der records plötzlich
keine  rec.a und rec.b mehr, sondern einfach nur noch a und b.
Wenn's zufällig globale a und b gab, dann gibt's die eben vorrübergehend
nicht mehr. Bring das mal einem Parsergenerator nahe, wenn Variablen-
namen eben zwischendurch für etwas völlig anderes mit möglicherweise
einem anderen Typ stehen.

In Jensen-Wirth's Pascal, User Manual and Report (insgesamt ein
beeindruckend dünnes Heftchen für seine Wichtigkeit) ist im Anhang
die ganze Grammatik in BNF und die Blasendiagramme für den Parser
drinnen.

Und das ganze UCSD-Pascalsystem konnte man auf einem Z80 mit
AT-Floppies compilieren.

Ja, für den SCPI-Parser auf dem BeagleBoneBlack nehme ich
schon den yacc/bison und gcc. Für jeden Topf den passenden Deckel.

Gerhard

[toc] | [prev] | [next] | [standalone]

#264327

On 23.09.19 14:15, Gerhard Hoffmann wrote:

> Und er muss dir auch nichts liefern, du hast nichts bei ihm gekauft.

Wenn jemand groß Sprüche klopft, wie einfach das doch alles von Hand
sei, Lexer/Parser für komplexe Grammatiken zu schreiben (zum Beispiel
der von C), und dann in der Praxis halt schon bei simpelsten Beispielen
voll auf die Nase fliegt, dann ist das ja schon ein interessantes Ergebnis.

Klar muss er nichts liefern, hat er ja bisher auch nie. Sobald es
konkret wird, immer schön kneifen. Typisch Schäwtzer eben.

>> *TOMMELWIRBEL*
> 
> Wirklich bewiesen hast du garnix. 

Doch, dass der Parser, den DoDi geschrieben hat, eben nur (wie ich
ursprünglich vermutet hatte) ein (beliebiges) Subset von C parst. Wenn
du das bestreitest, kannst du es ja gerne selber ausprobieren.

> Du hast ein paar Exotencompiler
> aufgezählt die einen Parsergenerator benutzen,

Das sind keine Compiler, hast du die Links mal angesehen? Die erzeugen
teilweise nur einen AST und sind Libraries.

> aber die wichtigen
> Compiler, die jeder hernimmt, wie gcc oder clang benutzen rekursiven
> Abstieg.

Das ist *professionelle* Software. Mit hunderttausenden Personenstunden,
die da reingeflossen sind, sowohl in clang als auch in gcc. Und ich habe
ausführlich beschrieben, warum die das so machen -- sowohl clang als
auch gcc parsen eben auch C++, für das es keine ausdefinierte Grammatik
gibt (als Bonus gibt's bessere Diagnostics dazu). Insofern sind die als
Beispiel *völlig* ungeeignet, denn es ging grundsätzlich darum, ob und
wie schwierig es ist, Lexer/Parser von Hand zu schreiben.

Ohne Not schreibt *niemand* einen Parser von Hand, auch nicht gcc und
clang. Und wenn man sich dazu entscheidet, ist das *weitaus*
schwieriger, als einen Parsergenerator zu nehmen.

> Pascal nimmt auch rekursiven Abstieg. Und da sind Bösartigkeiten
> wie das with-statement drinnen:
> 
> with record_variablenliste do begin ... end
> 
> und zwischen begin & end sind die Komponenten der records plötzlich
> keine  rec.a und rec.b mehr, sondern einfach nur noch a und b.
> Wenn's zufällig globale a und b gab, dann gibt's die eben vorrübergehend
> nicht mehr. Bring das mal einem Parsergenerator nahe, wenn Variablen-
> namen eben zwischendurch für etwas völlig anderes mit möglicherweise
> einem anderen Typ stehen.

Ich weiß echt nicht, wieso du ständig mit Pascal anfängst, das hat mit
dem Thema überhaupt nichts zu tun. Ich habe nie bestritten, dass
Recursive Descent ein ordentliches oder geeignetes Parsing-Verfahren
ist. Ich sage lediglich, dass das Schreiben eines Parsers von Hand
RICHTIG viel schwieriger ist, als einen Parsergenerator zu nehmen und
dass man deswegen dafür einen RICHTIG guten Grund (und viel, viel mehr
Zeit) braucht. Und bin extrem skeptisch wenn sich jemand hinstellt und
sagt "das hab ich schon gemacht, war ganz einfach". Weil >40000 Zeilen
Code zu schreiben, nur fürs Parsing, ist eben NICHT einfach.

> Ja, für den SCPI-Parser auf dem BeagleBoneBlack nehme ich
> schon den yacc/bison und gcc. Für jeden Topf den passenden Deckel. 

Ja, da gehe ich mit. Wenn es einen guten Grund gibt, klar, dann schreibt
man sich seinen eigenen Parser. Damit kommen eine interessante Vorteile,
aber auch eben einige gewichtige Nachteile mit. Aber grundsätzlich die
Komplexität zu trivialisieren ist kein guter Ansatz.

Gruß,
Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264389

Am 23.09.2019 um 14:31 schrieb Johannes Bauer:
> On 23.09.19 14:15, Gerhard Hoffmann wrote:
>> Und er muss dir auch nichts liefern, du hast nichts bei ihm gekauft.
> 
> Wenn jemand groß Sprüche klopft, wie einfach das doch alles von Hand
> sei, Lexer/Parser für komplexe Grammatiken zu schreiben (zum Beispiel
> der von C), und dann in der Praxis halt schon bei simpelsten Beispielen
> voll auf die Nase fliegt, dann ist das ja schon ein interessantes Ergebnis.

Ich warte ja auf das Gegenbeispiel, also: deinen C-Parser.

>> aber die wichtigen
>> Compiler, die jeder hernimmt, wie gcc oder clang benutzen rekursiven
>> Abstieg.
> 
> Das ist *professionelle* Software. Mit hunderttausenden Personenstunden,
> die da reingeflossen sind, sowohl in clang als auch in gcc. Und ich habe
> ausführlich beschrieben, warum die das so machen -- sowohl clang als
> auch gcc parsen eben auch C++, für das es keine ausdefinierte Grammatik
> gibt

*Das* ist Geschwätz. Selbstverständlich hat C++ eine Grammatik. Zu
finden im Standard-Dokument unter "Annex A" sowie in Fragmenten in den
einzelnen Kapiteln. Sie ist halt nur nicht LL(1).

> Ohne Not schreibt *niemand* einen Parser von Hand, auch nicht gcc und
> clang. Und wenn man sich dazu entscheidet, ist das *weitaus*
> schwieriger, als einen Parsergenerator zu nehmen.

Nein. Sage ich als einer, der routinemäßig Parser per Hand baut.

>> Pascal nimmt auch rekursiven Abstieg. Und da sind Bösartigkeiten
>> wie das with-statement drinnen:
>>
>> with record_variablenliste do begin ... end

(Das ist übrigens parserseitig völlig trivial. Für Pascal musst du nicht
wissen, was das Wort 'x' bedeutet, um aus 'x(y)' einen AST bauen zu können.)

>> und zwischen begin & end sind die Komponenten der records plötzlich
>> keine  rec.a und rec.b mehr, sondern einfach nur noch a und b.
>> Wenn's zufällig globale a und b gab, dann gibt's die eben vorrübergehend
>> nicht mehr. Bring das mal einem Parsergenerator nahe, wenn Variablen-
>> namen eben zwischendurch für etwas völlig anderes mit möglicherweise
>> einem anderen Typ stehen.
> 
> Ich weiß echt nicht, wieso du ständig mit Pascal anfängst, das hat mit
> dem Thema überhaupt nichts zu tun. Ich habe nie bestritten, dass
> Recursive Descent ein ordentliches oder geeignetes Parsing-Verfahren
> ist. Ich sage lediglich, dass das Schreiben eines Parsers von Hand
> RICHTIG viel schwieriger ist, als einen Parsergenerator zu nehmen und
> dass man deswegen dafür einen RICHTIG guten Grund (und viel, viel mehr
> Zeit) braucht. Und bin extrem skeptisch wenn sich jemand hinstellt und
> sagt "das hab ich schon gemacht, war ganz einfach". Weil >40000 Zeilen
> Code zu schreiben, nur fürs Parsing, ist eben NICHT einfach.

Das, was du beim Schreiben der Grammatik sparst - wenn überhaupt was -
zahlst du beim Debuggen drauf. Wo muss ich jetzt die Aktionen
platzieren? Wie bekomme ich das Speicherleck-frei? Wie bekomme ich
gescheite Fehlermeldungen außer "parse error"? Wie erhole ich mich am
besten von einem Parser-Fehler? (Nächstes Semikolon suchen? Oder doch
lieber geschweifte Klammern? Oder 'END'-Schlüsselwort?)

Und - und das ist einer der Gründe, einen C-Parser per Hand zu machen -
in einem händischen Parser ist es trivial, Feedback zu geben, was für
ein Ding 'x' in 'x*y[3]' ist, denn abhängig davon wird der Rest
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

[toc] | [prev] | [next] | [standalone]

#264393

On 24.09.19 19:18, Stefan Reuther wrote:

>> Wenn jemand groß Sprüche klopft, wie einfach das doch alles von Hand
>> sei, Lexer/Parser für komplexe Grammatiken zu schreiben (zum Beispiel
>> der von C), und dann in der Praxis halt schon bei simpelsten Beispielen
>> voll auf die Nase fliegt, dann ist das ja schon ein interessantes Ergebnis.
> 
> Ich warte ja auf das Gegenbeispiel, also: deinen C-Parser.

Nur weil einen Parser von Hand schreiben schwer ist, heißt das noch
lange nicht, dass einen Parser mit Generator schreiben leicht ist.

Aber wenn ich ein Beispiel liefern würde, dann kann ich dir immerhin
versichern, dass das nicht so grütze-mäßig Segfaulten würde wie DoDis
Beispiel. Denn DAS ist Pfusch, völlig egal wie man parst.

>> auch gcc parsen eben auch C++, für das es keine ausdefinierte Grammatik
>> gibt
> 
> *Das* ist Geschwätz. Selbstverständlich hat C++ eine Grammatik. Zu
> finden im Standard-Dokument unter "Annex A"

Du kannst offenbar keine Standards lesen. Denn da steht ganz klar
zuerstmal: Annex A (informative) -- muss ich dir jetzt den Unterschied
zwischen informative und normative erklären?

Und dann nochmal überdeutlich: "This summary of C ++ syntax is intended
to be an aid to comprehension. It is not an exact statement of the
language."

> sowie in Fragmenten in den
> einzelnen Kapiteln. 

Genau, verteilt über ~1300 Seiten, aber eben nicht ausdefiniert (und
genau das habe ich geschrieben, keine ausdefinierte Grammatik).

> Sie ist halt nur nicht LL(1).

Hat auch nie irgendjemand behauptet, völliges Strohmann-Argument.

>> Ohne Not schreibt *niemand* einen Parser von Hand, auch nicht gcc und
>> clang. Und wenn man sich dazu entscheidet, ist das *weitaus*
>> schwieriger, als einen Parsergenerator zu nehmen.
> 
> Nein. Sage ich als einer, der routinemäßig Parser per Hand baut.

Puh, naja, das ist jetzt Aussage gegen Aussage. Du findest das Schreiben
von Hand einfach, ich habe gerne Unterstützung von Werkzeugen.

> Das, was du beim Schreiben der Grammatik sparst - wenn überhaupt was -
> zahlst du beim Debuggen drauf. Wo muss ich jetzt die Aktionen
> platzieren? Wie bekomme ich das Speicherleck-frei? Wie bekomme ich
> gescheite Fehlermeldungen außer "parse error"? Wie erhole ich mich am
> besten von einem Parser-Fehler? (Nächstes Semikolon suchen? Oder doch
> lieber geschweifte Klammern? Oder 'END'-Schlüsselwort?)

Das ist wohl richtig, eine ordentliche Grammatik zu schreiben ist auch
alles andere als leicht. Und tatsächlich ist Debugging von Grammatiken
elendige Arbeit.

> Und - und das ist einer der Gründe, einen C-Parser per Hand zu machen -
> in einem händischen Parser ist es trivial, Feedback zu geben, was für
> ein Ding 'x' in 'x*y[3]' ist, denn abhängig davon wird der Rest
> 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.

Einen Tod muss man sterben. Vermutlich ist dann wohl ausschlaggebend,
womit man am meisten Erfahrung hat.

Viele Grüße,
Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264481

Am 24.09.2019 um 20:47 schrieb Johannes Bauer:
> On 24.09.19 19:18, Stefan Reuther wrote:
>>> Wenn jemand groß Sprüche klopft, wie einfach das doch alles von Hand
>>> sei, Lexer/Parser für komplexe Grammatiken zu schreiben (zum Beispiel
>>> der von C), und dann in der Praxis halt schon bei simpelsten Beispielen
>>> voll auf die Nase fliegt, dann ist das ja schon ein interessantes Ergebnis.
>>
>> Ich warte ja auf das Gegenbeispiel, also: deinen C-Parser.
> 
> Nur weil einen Parser von Hand schreiben schwer ist, heißt das noch
> lange nicht, dass einen Parser mit Generator schreiben leicht ist.
> 
> Aber wenn ich ein Beispiel liefern würde, dann kann ich dir immerhin
> versichern, dass das nicht so grütze-mäßig Segfaulten würde wie DoDis
> Beispiel.

Da wäre ich mir nicht so sicher, denn Ressourcenmanagement zumindest mit
yacc ist nicht einfach. Wer gackert muss auch legen.

(Mein zweites größeres Parserprojekt war vor >20 Jahren bei "Jugend
Forscht", ist also nicht so, dass ich nicht legen könnte.)

>>> auch gcc parsen eben auch C++, für das es keine ausdefinierte Grammatik
>>> gibt
>>
>> *Das* ist Geschwätz. Selbstverständlich hat C++ eine Grammatik. Zu
>> finden im Standard-Dokument unter "Annex A"
> 
> Du kannst offenbar keine Standards lesen. Denn da steht ganz klar
> zuerstmal: Annex A (informative) -- muss ich dir jetzt den Unterschied
> zwischen informative und normative erklären?

Danke, sehr freundlich. (Mein ca. fünftes größeres Parserprojekt war
Teil eines C++-Compilers für das VFiasco-Projekt. C++-Standard kenn ich.)

> Und dann nochmal überdeutlich: "This summary of C ++ syntax is intended
> to be an aid to comprehension. It is not an exact statement of the
> language."

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.

>> sowie in Fragmenten in den
>> einzelnen Kapiteln. 
> 
> Genau, verteilt über ~1300 Seiten, aber eben nicht ausdefiniert (und
> genau das habe ich geschrieben, keine ausdefinierte Grammatik).

Was wäre denn eine "ausdefinierte Grammatik"?

Die ernsthafte Schwäche, die diese Grammatik hat, ist, dass sie zwischen
den Ebenen "lexikalische Analyse", "Präprozessor" und "syntaktische
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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.sci.electronics

csiph-web