Syntax von Programmiersprachen

(1)

Syntax von Programmiersprachen

(2)

SEP 209

Programmiersprachen

Sprache = Menge von Wörtern, typischerweise unendlich Programmiersprache: Wörter repräsentieren Programme Programm kann auf einem Computer (evtl. nur abstrakte

Maschine) ausgef¨uhrt werden und induziert somit eine Berechnung Bsp.:

• Javaprogramme werden in JVM ausgef¨uhrt

• arithmetische Ausdr¨ucke im Taschenrechner evaluieren

• Tastenkombinationen zur Steuerung des Handys

• . . .

(3)

SEP 210

Begriffsbildung

typisches Problem: gegeben ProgrammP, potentiell aus der SpracheL, f¨uhre dies aus

• Syntax: beschreibt die Programmiersprache; welche W¨orter sind korrekte Programme, welche nicht

• Semantik: beschreibt die Bedeutung eines Programms; wie ist dieses auszuf¨uhren

• Interpreter: Programm, welches einen Computer steuert, um andere Programme auszuf¨uhren

• Compiler: Programm, welches Programme einer SpracheLin

¨aquivalente Programme einer anderen Sprache L⁰ (typischerweise Maschinensprache) ¨ubersetzt

• Lexer/Parser: Programme, die aus einem Wort, gegeben als String, eine baumartige Struktur bauen; werden benutzt, um die Struktur in Programmen zu erkennen

(4)

SEP 211

Syntax

Syntax von Programmiersprachen h¨aufig gegeben durch kontext-freie Grammatik (evtl. mit Nebenbedingungen), z.B.

hPrgi ::= . . .|while(hBExpi){ hPrgi } |. . . hBExpi ::= . . .| hBExpi<hBExpi |. . .

in diesem Beispiel wichtig:

• Teil, der aus hPrgi abgeleitet wird, ist einProgramm

• Teil, der aus hBExpiabgeleitet wird, ist ein boolescher Ausdruck

warum ist solch eine Unterscheidung wichtig?

Semantik besagt sicherlich, dass boolesche Ausdr¨ucke zutrue oder falseausgewertet werden; Auswertung eines Programm ist jedoch anders

(5)

SEP 212

Notwendigkeit des Parsens

zum Verstehen und Ausf¨uhren des Programms while (z < x) {

y = y*2; z++

}

ist es notwendig, darin Struktur zu erkennen, z.B.

while

z<x ;

y=y∗2 z+ + beachte:

• Links-Mitte-Rechts-Durchlauf des Baums liefert nicht originale Stringrepr¨asentation des Programms

• Ausf¨uhrung des Programms abh¨angig von Art des Teilbaums (z.B. Programm vs. bool. Ausdruck)

(6)

SEP 213

Konkrete Syntax

konkrete Syntaxeiner Programmiersprache beschreibt genau die Zeichenketten, die g¨ultige Programme beschreiben, z.B.

hPrgi ::= . . .| hIdi=hExpi

hIdi ::= hAlphai(hAlphai ∪ hNumi)^∗

beachte: in diesem Fall gar nicht so konkret, gewisser Grad an Abstraktion bereits vorhanden: Whitespaces evtl. implizit zugelassen

x3=x1 x3 = x1 x3 =

x1

konkrete Syntax wird dazu verwendet, in Programmen Struktur zu erkennen, also f¨ur denParser

Abstraktionsgrad bzgl. Whitespaces o.¨a. wird vom Lexer gehandhabt

(7)

SEP 214

Abstrakte Syntax

konkrete Syntax stellt oft zuviel Information bereit, welche nur zum Erkennen der Programmstruktur notwendig ist, aber zu Redundanz in Ableitungsb¨aumen f¨uhrt (Beispiel folgt)

abstrakte Syntaxbeschreibt ebenfalls Prgrammstruktur, aber auf abstrakterer Ebene, z.B.

hPrgi ::= . . .|Id=hExpi

hier also z.B. Bezeichner als Terminale aufgefasst, die zus¨atzlich einen Namen haben, z.B.Id(x3)

Grund: f¨ur Auswertung von Programmen oder Ausdr¨ucken ist lexikalische Struktur von Bezeichnern uninteressant, wichtig ist nur zu wissen, ob es ein Bezeichner oder Ausdruck oder Konstante etc.

ist

Parser ↔ konkrete Syntax ↔ abstrakte Syntax ↔ Interpreter

(8)

SEP 215

Konkrete vs. abstrakte Syntax

Bsp.:einfache Sprache boolescher Ausdrücke über 0,1mit∨,∧ mit üblicher Auswertung

hBExpi ::=0|1| hBExpi ∨ hBExpi | hBExpi ∧ hBExpi Ausdruck0∧0∨1is g¨ultig bzgl. dieser Grammatik, aber was ist sein Wert?

Grammatik istmehrdeutig

hBExpi

hBExpi ∧

0

hBExpi

??

∨ hBExpi

0

hBExpi

??

1

hBExpi

∨ hBExpi

??

1 hBExpi

∧ hBExpi

0

hBExpi

??

0

(9)

SEP 216

Mehrdeutigkeiten

Grammatik ist mehrdeutig, wenn es ableitbare W¨orter mit mehr als einem Ableitungsbaum gibt

keine eindeutige Struktur; Auswerten nicht eindeutig Mehrdeutigkeiten können oft durch Präzedenzregelnaufgelöst werden; hier: “∧bindet stärker als ∨”

Umgang mit Pr¨azedenzen:

• Parser so programmieren, dass er sie ber¨ucksichtigt, oder

• in Grammatik einbauen

(10)

SEP 217

Mehrdeutigkeiten eliminieren

hier z.B.

hBExpi ::= hBExpi

∨ hBExpi∗

| hBExp⁰i hBExp⁰i ::= hBExp⁰i

∧ hBExp⁰i∗

|(hBExpi)|0|1

nur noch ein Ableitungsbaum f¨ur besagtes Wort mit richtiger Pr¨azedenz

hBExpi

∨ hBExpi

hBExp⁰i

∧

hBExpi

??

hBExp⁰i

hBExp⁰i 1

0

hBExp⁰i

??

0

(11)

SEP 218

Vorteile abstrakter Syntax

obiger Ableitungsbaum ist unn¨otig gross und Auswertung von hBExpi und hBExp⁰i unterscheidet sich nicht wesentlich

Struktur und n¨otige Information kann auch so gespeichert werden

∨

1

??

?

∧

0

??

? 0

hier ben¨otigt: innere Knoten sind Operatoren, Bl¨atter sind Konstanten

leicht abzubilden in Klassendiagramm

(12)

SEP 219

Vorgehensweise

hier: ProgrammierspracheAntBraingegeben

• konkrete Syntax durch kontext-freie Grammatik

• abstrakte Syntax durch UML-Klassendiagramm was ist zu tun?

1 aus Grammatik extrahieren: was sind die wichtigen Teile einer Eingabe? Nicht einzelne Zeichen, sondern Schlüsselwörter, Bezeichner, Konstanten, Befehle, . . . , genannt Tokens Lexer schreiben, der Zeichenkette in Liste von Tokens zerlegt / übersetzt

2 aus konkreter Syntax einen Parser bauen, der Listen von Tokens in Ableitungsbäume umwandelt; diese möglichst gleich als baumförmige Objektstrukturen der abstrakten Syntax erzeugen

(13)

SEP 220

Beispiel

gesamtes Vorgehen beispielhaft gezeigt anhand einfacher Sprache arithmetischer Ausdr¨ucke

hNumi ::= hDigiti⁺ hDigiti ::= 0|. . .|9

hIdi ::= hAlphai hAlphai ∪ hDigiti∗

hAlphai ::= a|. . .|z|A|. . .|Z

beachte: Grammatik ist mehrdeutig

(14)

SEP 221

Beispiel mit eindeutiger Grammatik

Präzedenzregel in Grammatik einbauen und zusätzlich Ende der Eingabe in Grammatik verlangen, damit der Parser später vollständige Eingaben verarbeitet

hIExpi ::= hIExp₁iEOF hIExp₁i ::= hIExp₂i

+hIExp₂i∗

hIExp₂i ::= hIExp₃i

∗hIExp₃i∗

hIExp₃i ::= (hIExp₁i)| hIExpAtomi hIExpAtomi ::= hNumi | hIdi |rand

...

(in abstrakter Syntax w¨urde manhNumiund hIdi als Tokens betrachten)

(15)

SEP 222

Token

sinnvolle Gruppierung von Teilen einer Zeichenkette in Tokens:

EOF,Identifier,Keyword,Number,Symbol einige Tokens haben Werte:

• ein String beiIdentifier – der Name

• ein Integer bei Number– sein Wert

• ein Name bei Keyword – um welches es sich handelt; hier gibt es jedoch lediglich rand

• ein Name bei Symbol– es gibt die Symbole(,),+,*, die gut als Aufz¨ahlungstyp modelliert werden k¨onnen

(16)

SEP 223

Lexer

nimmt Zeichenkette und wandelt diese in Liste von Tokens um, z.B.

47 + x7 + rand) * (016 +)rand34 wird zu

Number(47), Symbol("+"), Identifier("x7"), Symbol("+"),

Keyword(rand), Symbol(")"), Symbol("*"), Symbol("("), Number(16), Symbol("+"), Symbol(")"), Identifier("rand34")

beachte:

• Lexer ¨uberpr¨uft nicht, ob Zeichenkette herleitbar ist (Parser)

• Lexing kann auch fehlschlagen, hier z.B. beix - 3

• Java-Klasse Scanner hier nicht geeignet, um Lexer zu konstruieren

(17)

SEP 224

Parser

zur Erinnerung: Parser erhält Liste von Tokens und konstuiert daraus Ableitungsbaum bzgl. (abstrakter) Syntax, der diese Liste als Blätter und Startsymbol der Grammatik als Wurzel enthält es gibt allgemeines Verfahren zum Parsen kontext-freier Grammatiken

• l¨auft in ZeitO(n³) bei Eingabel¨angen

• konstruiert endliche Repr¨asentation aller Ableitungsb¨aume beides ist nicht von Vorteil (bei eindeutigen Grammatiken)

Ausweg: Unterklassen der kontext-freien Sprachen, die einfacheres und damit evtl. auch schnelleres (z.B. inO(n)) Parsen erlauben

(18)

SEP 225

Bottom-Up vs. Top-Down Parsen

im Prinzip gibt es zwei Arten von Parsern

• Bottom-Up

• finde Teil der Eingabe der FormB₁. . .B_k, sodass es Regel A::=B₁. . .B_k gibt; ersetze diesen Teil durchA

• endet, wenn gesamte Eingabe durch StartsymbolS ersetzt wurde

• Problem: normalerweise keine eindeutige Ersetzung m¨oglich

• Top-Down

• interessant ist nur, ob Eingabet1. . .tn aus StartsymbolS herleitbar ist

• beginnt sozusagen an der WurzelS

• versucht, sukzessive Teilb¨aume darunter durch Anwenden einer Regel zu konstruieren

• Problem: normalerweise stehen mehrere Regeln zur Auswahl

• endet, wenn Bl¨atterfront der Eingabeliste entspricht

(19)

SEP 226

Beispiel Bottom-Up Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExp⁰i hBExp⁰i hBExp⁰i hBExp⁰i

hBExpi

hBExpi hBExpi

(20)

SEP 227

Beispiel Bottom-Up Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExp⁰i hBExp⁰i

hBExp⁰i

hBExp⁰i hBExpi

hBExpi hBExpi

(21)

SEP 228

Beispiel Bottom-Up Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExp⁰i

hBExp⁰i hBExpi

hBExpi hBExpi

(22)

SEP 229

Beispiel Bottom-Up Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExp⁰i

hBExp⁰i hBExpi

hBExpi

(23)

SEP 230

Beispiel Bottom-Up Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExp⁰i hBExp⁰i hBExp⁰i

hBExp⁰i hBExpi

hBExpi

(24)

SEP 231

Beispiel Bottom-Up Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExpi

(25)

SEP 232

Beispiel Bottom-Up Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExpi

(26)

SEP 233

Beispiel Bottom-Up Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExpi

hBExpi hBExpi

(27)

SEP 234

Top-Down Parser

allgemeine Funktionsweise:

Parse(NonterminalA, TokenList [t₁, . . . ,t_n]) w¨ahle Regel A::=B₁. . .B_m

w¨ahlei₁ ≤i₂ ≤. . .i_m≤i_m+1 miti₁ = 1,i_m+1=n+ 1 forj = 1, . . . ,mdo

Parse(B_i, [t_i_j, . . . ,t_i_j+1−1])

hier zur Vereinfachung nur einRecognizer, keinParser

muss also noch beim R¨ucksprung konstruierten Ableitungsbaum liefern

Verfahren ist nichtdeterministisch, braucht also noch Strategien, um W¨ahlen deterministisch zu machen; h¨angt von Sprachklasse ab

(28)

SEP 235

Beispiel Top-Down Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExpi

(29)

SEP 236

Beispiel Top-Down Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExpi

hBExpi hBExpi

(30)

SEP 237

Beispiel Top-Down Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExp⁰i hBExp⁰i

hBExp⁰i

hBExpi

hBExpi hBExpi

(31)

SEP 238

Beispiel Top-Down Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExp⁰i hBExp⁰i

hBExp⁰i

hBExpi

hBExpi hBExpi

(32)

SEP 239

Beispiel Top-Down Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExp⁰i hBExp⁰i

hBExpi

hBExpi hBExpi

(33)

SEP 240

Beispiel Top-Down Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExpi

hBExpi hBExpi

(34)

SEP 241

Beispiel Top-Down Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExpi

hBExpi hBExpi

(35)

SEP 242

Beispiel Top-Down Parsen

Grammatik:

hBExpi ::= hBExpi

∨ hBExpi∗

∧ hBExp⁰i∗

|(hBExpi)|0|1

Parsen:

0 ∧ 0 ∨ 1

hBExpi

hBExpi hBExpi

(36)

SEP 243

LL(k )-Sprachen

gr¨oßeres Problem beim top-down Parsen: Wahl der Regel

LL(k)-Sprache ist Sprache, f¨ur die es eine LL(k)-Grammatik gibt Def.:Sei G Grammatik ¨uber Alphabet Σ, α Satzform,k ∈N

firstk(α) = {v ∈Σ^k | ∃β, α⇒^∗ vβ}

Def.:G ist LL(k)-Grammatik, wenn f¨ur alle Nonterminals A und alle RegelnA::=α,A::=β mitα6=β und alle Satzformen γ und W¨orterv mitS ⇒^∗vAγ:

first_k(αγ)∩first_k(βγ) =∅

soll heißen: bei einer LL(k)-Sprache erkennt man anhand von h¨ochstens k der n¨achsten Tokens, welche Regel anzuwenden ist

(37)

SEP 244

LL(k )-Parsen

allgemeine Vorgehensweise:

Parse(NonterminalA, TokenList [t₁, . . . ,t_n])

w¨ahle anhand vont₁, . . . ,t_k eindeutige RegelA::=B₁. . .B_m w¨ahlei₁≤i₂ ≤. . .i_m ≤i_m+1 miti₁= 1, i_m+1 =n+ 1 forj = 1, . . . ,m do

Parse(B_i, [t_i_j, . . . ,t_i_j+1−1])

noch zu eliminieren: Nichtdeterminismus bzgl. Wahl der Zerlegung

• finde Zerlegung beim Parsen selbst

• parse erst [t1, . . . ,tn] bzgl. B1

• dies reduziert dann [t1, . . . ,ti−1] f¨ur eini zu einem Ableitungsbaum mit WurzelB₁

• parse dann [ti, . . . ,tn] bzgl. B2, etc.

(38)

SEP 245

Beispiel

dies ist eine LL(1)-Grammatik

hIExpi ::= hIExp₁iEOF hIExp₁i ::= hIExp₂i

+hIExp₂i∗

∗ hIExp₃i∗

hIExp₃i ::= (hIExp₁i)| hIExpAtomi hIExpAtomi ::= Num|Id |rand

betrachte Regeln fürhIExp₁i und hIExp₂iz.B. als Abkürzung für hIExp₁i ::= hIExp₂i hIExpSeq₁i

hIExpSeq₁i ::= +hIExp₂i hIExpSeq₁i |

beachte: Kleene-Sterne hier immer zu lesen als “soviel wie m¨oglich mit dieser Regel parsen”

(39)

SEP 246

Beispiel LL(1)-Parsen

hIExpi ::= hIExp₁iEOF hIExp1i ::= hIExp2i

+hIExp2i∗

∗ hIExp₃i∗

hIExp3i ::= (hIExp1i)| hIAtomi hIAtomi ::= Num|Id|rand

( 3 + rand ) ∗ 4 EOF

hIAtomi hIAtomi hIAtomi

hIExp₃i hIExp₃i hIExp₃i

hIExp₂i

noch∗ hIExp₃i. . .?

hIExp₂i

hIExp1i

noch +hIExp₂i. . .?

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(40)

SEP 247

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(41)

SEP 248

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(42)

SEP 249

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(43)

SEP 250

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(44)

SEP 251

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(45)

SEP 252

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(46)

SEP 253

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIExp₃i

hIExp₃i hIExp₃i

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(47)

SEP 254

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIAtomi

hIAtomi hIAtomi

hIExp₃i

hIExp₃i hIExp₃i

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(48)

SEP 255

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIAtomi

hIAtomi hIAtomi

hIExp₃i

hIExp₃i hIExp₃i

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(49)

SEP 256

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIAtomi

hIAtomi hIAtomi

hIExp₃i

hIExp₃i hIExp₃i

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(50)

SEP 257

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIAtomi

hIAtomi hIAtomi

hIExp₃i

hIExp₃i hIExp₃i

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(51)

SEP 258

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIAtomi

hIAtomi hIAtomi

hIExp₃i hIExp₃i

hIExp₃i

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(52)

SEP 259

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIAtomi hIAtomi

hIAtomi

hIExp₃i hIExp₃i

hIExp₃i

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(53)

SEP 260

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIAtomi hIAtomi

hIAtomi

hIExp₃i hIExp₃i

hIExp₃i

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(54)

SEP 261

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIAtomi hIAtomi

hIAtomi

hIExp₃i hIExp₃i

hIExp₃i

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF

(55)

SEP 262

Beispiel LL(1)-Parsen

+hIExp2i∗

∗ hIExp₃i∗

( 3 + rand ) ∗ 4 EOF

hIAtomi hIAtomi

hIAtomi

hIExp₃i hIExp₃i

hIExp₃i

hIExp₂i

hIExp1i

hIExp3i

noch )

hIExp₂i

hIExp₁i

hIExpi

nochEOF