Kap.4, del 2: Top Down Parsering Kap. 5, del 1: Bottom Up Parsing INF5110, 7/ Legger ut en oppgave til kap. 4 (se beskjed).

Transkript

1 Kap.4, del 2: Top Down Parsering Kap. 5, del 1: Bottom Up Parsing INF5110, 7/ Legger ut en oppgave til kap. 4 (se beskjed). tein Krogdahl Ifi, UiO Merk: Av de foilene som ble delt ut på papir på forelesningen 5/2 utgår nr. 39 til 43 (og nr. 44 blir gjentatt her). Alle foilene f.o.m. nr. 39 er tatt bort i det som er lagt ut i pdf-format (Kap og kap utgår i forhold til i fjor) 1

2 Når kompilatoren oppdager feil Minstekrav: Tester løpende at programmet er OK, og gir fornuftig feilmelding ved feil (men stopper) Vanlig krav ved feil ( error recovery ): Gir fornuftig feilmelding. Blar forbi feilen og fortsetter kompileringen (blar forbi så lite som mulig). Vanligvis vil man slutte å lage maskinkode etter feil (Men noe feilrettende kompilatorer forsøker det lite brukt) Det er for syntaksfeil det er vanskeligst å ta opp tråden etter feil. Viktig: Forsøke å unngå feilmeldinger som bare er følgefeil Rapportere feil så tidlig som mulig, helst så snart det man har lest ikke kan forlenges til et riktig program Man må passe på at man ikke blir gående i løkke rapportere feil uten å lese noe fra input. 2

3 Behandling av yntaksfeil ved recursive decent parsering. Metode: Panic mode og synkroniserings-mengde <program> begin <deklsekv>; <setningssekv> end; ynchset (stakk eller parameter): end <stmnt>; <stmnt>; <stmnt>;... ; First(stmt) navn if while for if <expr> then <stmnt> [ else <stmnt> ] then First(stmt) else <term> ± <term> ± <term>... <factor> * <factor> *<factor>... (<expr>) + - First(term) * First(factor) ) ( tall navn <term> ± <term> ± <term> ( tall navn 3

4 yntaksfeil ved rec. descent 2 Ut fra skissen er det greit å finne: - hvem som skal ta opp tråden - hvor denne skal starte igjen Algoritme: Unionen av alle på stakken kalles synkroniseringsmengden, M For hvert input-symbol framover, inntil man eventuelt finner $: Om det finnes i M: Den tilsvarende proc skal ta opp tråden Den vet selv hvor den skal fortsette, med dette symbolet Om input-symbol ikke er i M: gå til neste input-symbol, og gjenta Det som ikke er greit, er å programmere dette uten at den vakre strukturen ved rec. descent blir helt ødelagt. 4

5 Uttrykksprosedyrer ved error recovery Filosofien her er litt annerledes (og noe uklar?) Også { +, - }?? Hovedfilosofi: checkinput kalles to ganger: Først for å sjekke at konstruksjonen starter riktig, etterpå for å sjekke at symbolet etter konstruksjonen er lovlig. if token in {(,number} then Bruker parameter, ikke stakk Prosedyrene må selv ta opp tråden riktig når de får igjen kontrollen: match(t) er som før: - tester input mot t -kaller eventuelt error (som nå returnerer!) - kaller ikke scanto(...) Hvorfor ikke også synchset? 5

6 Kap. 5: Bottom up -parsering (nedenfra-og-opp) A B B A t 1 t 2 t 3 t 7 t 4 t 5 t 6 LR-parsering og grammatikker -LR(0) -LR(1) -LR(1) -LALR(1) -Autimatisert -YACC, Bison, CUP ( LALR(1) ) 6

7 Til sammenlikning: Top down -parsering C B A Hvilket alternativ for A? Input Analysert og funnet OK token kal matches mot resten i prosedyrene 7

8 Prinsippet og datastrukturen for LR-parsering A B t 7... A t 4 t 5 t 1 B B t 2 t 3 A t 6... Anta at grammatikken er entydig, og at vi kjenner syntaks-treet for setningen: A B B A t 1 t 2 t 3 t 4 t 5 t 6 t 7 LRparsering : Ha en stakk for det som er lest (altså omvendt av LL-parsering med stakk) Gjør reduksjonen av et subtre når det ligger på toppen av stakken 8

9 Prinsippet og datastrukturen LR-parsering II A B t 7... A t 4 t 5 t 1 B B t 2 t 3 A t 6... ett på ny ytterste produksjon A B B A t 1 t 2 t 3 t 4 t 5 t 6 t 7 Anta at grammatikken er entydig, og anta at vi kjenner syntaks-treet for setningen: Ha en stakk for det som er lest (og redusert!) Gjør reduksjonen av et subtre når subtreet ligger på toppen av stakken. Da erstatter vi dette med den ikke-terminalen som produserte dette subtreet. Dette tilsvarer en bestemt produksjon brukt omvendt tart-situasjonen: $ t 1 t 2 t 3 t 4 t 5 t 6 t 7 $ stakk input lutt-situasjonen: $ $ stakk input 9

10 Prinsippet med LR-parsering III A B t 7... A t 4 t 5 t 1 B B t 2 t 3 A t 6... B A B A t 1 t 2 t 3 t 4 t 5 t 6 t 7 stakk input $ t 1 t 2 t 3 t 4 t 5 t 6 t 7 $ $ t 1 t 2 t 3 t 4 t 5 t 6 t 7 $ $ t 1 t t 2 3 t 4 t 5 t 6 t 7 $ $ t 1 t 2 t t 3 4 t 5 t 6 t 7 $ $ t 1 B t 4 t 5 t 6 t 7 $ $ A t 4 t 5 t 6 t 7 $ $ A t t 4 5 t 6 t 7 $ $ A t 4 t t 5 6 t 7 $ $ A A t 6 t 7 $ $ A A t t 6 7 $ $ A B t 7 $ $ A B t 7 $ $ $ Får to typer steg: Reduksjon (på toppen av stakken med bestemt A α) Lesing ( skift ) av input over til stakken Dersom man kjenner syntakstreet for den aktuelle setning, er det lett å angi de rette stegene. MEN: Hvordan gjøre dette underveis uten å kjenne resten av input?? takk + input: Går gjennom en høyreavledning, i omvendt rekkefølge Husk at nå skal vi redusere input (bottom up) til startsymbolet, IKKE produsere input fra startesymbolet (slik vi gjorde top-down i kap 4)

11 Eksempel på LR-parsering E E E Boka: (takk + input) utgjør et stadium i en høyre-avledning. Den neste reduksjonen som skal gjøres, kalles situasjonens handle (håndtak). n + n 11

12 Eksempel på LR-parsering ε ( ) ε NB: ε blir litt rar 12

13 Typisk situasjon under LR-parsering Alle slike er redusert: A B Legg merke til forskjellen fra LL(1)-parsering med eksplisitt stakk: LL: Et bilde av det vi forventer å finne ligger på stakken LR: Et bilde av det vi har lest ligger på stakken $ t 1 t 2 t 3 t 4 t 5 t 6...t n $ stakken input s 1 s 2 s 3 s 4...s k lest input 13

14 Gitt en entydig grammatikk G. Denne behandles som følger for å lage en LR-parser: (Ikke alt er like tydelig beskrevet i boka, men bare boka er pensum) Vi ser på de mulig stakker som kan opptre, og ser disse som strenger over alfabetet {terminaler, ikke-terminaler}. Vi ser altså på: { utgjør stakken på ett eller annet stadium i LR-parsering av en setning i L(G)} Dette språket viser seg å være regulært, og kan beskrives av en NFA der: Tilstandene angis av itemer av formen: A X Y. Z Kantene kan beskrives nokså greit (kommer snart) Denne NFA-en gjør vi om til en DFA på vanlig måte (subset construction fra kap. 2) Tilstandene i denne DFA-en vil altså være mengder av itemer LR-parseringens hovedsetning (uformelt): Gitt en lovlig stakk og anta at den fører DFA-en angitt over til en (aksepterende!) tilstand T: Da vil mengden av itemer i T angi de mulige lokale forhold vi har ved det punktet vi nå er i i parseringen. Det er ofte flere muligheter/valg (ett for hvert item), siden vi ikke har tatt hensyn til resten av input. 14

15 Itemer: Hver produksjon i BNF-grammatikken gir opphav til et antall slike. For produksjonen : A αx β Lager vi itemer med punktum på alle plasser (punktumet er et Meta-symbol): A α X β A α X β A αx β A αx β Disse produksjonene med punktum kalles itemer Punktumet angir grovt sett situasjonen i dypeste del av parseringen i øyeblikket: Det til venstre for punktum er gjenkjent fra input, enten bare lest eller at deler av det er redusert til en ikke-terminal Det til høyre for punktum har vi enda ikke sett/lest 15

16 Dette er ikke fullt forklart i Kantene i NFA-en boka tilsvarer A Gitt en grammatikk G og en situasjon under passering av en setning s i L(G). Husk: Ingen slik på venstre side. De er redusert! α X η B A tilsvarer α X η ε β Y Opprinnelig input: takk: x $ 16

17 Eksempel på NFA E E E E + n E n Itemer (LR(0)itemer) 17

18 LR(0)-NFA (litt mer systematisk enn boka): start ε ε E.E ε E.E +n E E E E. E E. +n + E E+.n n E E+n. ε E.n n E n. LR(0)-DFA: