Serializare lexer (ca sa ne legam direct cu etapa 1).

Apoi parsare. Doua programe.

<instruction> ::= def <variable> = <expr>; |
                  while <expr> do <instruction> od |
                  if <expr> then <instruction> else <instruction> fi |
                  begin <instruction_list> end
                  
<instruction_list> ::= <instruction1> <instruction2> ... <instructionn>

<expr> ::= <expr> + <expr> | <expr> > <expr> | <expr> == <expr> | <variable> | <integer> 
                   

Combinam expresii din fisierul de referinta in specificatii. Mai sunt necesare detalii de clarificat.

Asemanator cu etapa 2. Folosim acelasi fisier de input, insa generam, in locul expresiilor PRENEX, nfa-uri, din lista de referinta.

Obiectivul etapei 2 este conversia unei expresii regulate la un Automat Finit Nedeterminist. Aceasta transformare este un prim pas in conversia unei specificatii (expresia regulata) intr-o implementare (AFN).

• un prim pas in aceasta etapa este parsarea expresiilor regulate, si construirea unui arbore pentru acestea. Spre exemplu, expresia: ab|c* are asociat arborele: UNION(CONCAT(a,b),STAR(c)). Datorita regulilor de precenta ale operatorilor, construirea acestui arbore este mai complicata, iar aceast task va fi amanat pentru etapa 4. Pentru a simplifica problema parsarii, expresiile vor fi prezentate in forma prenex.
• In forma prenex, operatorul preceda intotdeauna operanzii. Prezentate astfel, expresiile pot fi parsate mult mai usor. Spre exemplu, expresia de mai sus in forma prenex este UNION CONCAT a b STAR c. Observati similaritatea cu reprezentarea de arbore.
• Un test consta intr-un fisier .in ce contine:
  • pe prima linie, o expresie regulata in forma prenex
  • in continuare, cate un cuvant pe o linie
• Exemplu:

 
UNION CONCAT a b STAR c
abc
abcccc
ccc
ab

Implementarea voastra va primi un fisier de test <testxy.in>, va construi AFN-ul asociat expresiei regulate, apoi va verifica daca acesta accepta cuvintele din fisierul de test. Implementarea va scrie la output un fisier <testxy.out> ce va contine, pe cate o linie ACCEPT sau REJECT, pentru fiecare din cuvintele de la input. Exemplu de fisier de output pentru input-ul anterior:

REJECT
REJECT
ACCEPT
ACCEPT

Atentie: Implementarea va fi punctata doar in masura in care respecta cerinta (se construieste un AFN folosind algoritmul prezentat la curs).

Implementarea algoritmului lui Thomson este complicata de faptul ca starile sunt reprezentate ca intregi. Spre exemplu, AFN-urile pentru expresiile 0 si 1 vor avea fiecare cate doua stari, cel mai probabil numerotate de la 0 la 1. Pentru a construi AFN-ul pentru 0|1, trebuie sa renumerotam starile tinand cont de:

• faptul ca trebuie sa creem o noua stare initiala, si una finala
• starile AFN-ului pentru 0 trebuie sa fie disjuncte fata de cele ale lui 1
• logica AFN-urilor (ce cuvinte accepta) nu trebuie sa influentata de numerotare
• renumerotarea trebuie sa fie suficient de generala (vom mai avea nevoie de ea la etapa 3), astfel incat sa se comporte ca un map (o aplicatie de functie peste stari). In aceasta etapa, functia va fi +x.

Pentru a parsa forma Prenex, avem nevoie de o stiva care sa retina parti ale expresiei / operatii parsate deja. Vom interactiona in doua feluri cu stiva:

• reducerea expresiilor (sau cooling).
  • Exemplul 1: daca pe stiva avem: 0 | Star(?) | … , atunci vom inlocui cele doua expresii cu : Star(0) | …
  • Exemplul 2: daca pe stiva avem: Star(0) | Concat(?,?) | … , rezultatul reducerii va fi: Concat(Star(0),?) | …
• adaugarea expresiilor: vom citi operatorul sau operandul curent, si vom adauga elementele corespunzatoare pe stiva.

Implementarea voastra trebuie sa combine in mod eficient adaugarea cu reducerea.

Pentru a testa AFN-urile generate de voi, aveti nevoie de o modalitate de afisare a acestora in text. Va sugeram sa ii adaugati si modalitate grafica. Atasam un script Python3 care poate fi folosit pentru a desena AFN-uri:

• script-ul primeste in linia de comanda un fisier CSV ce contine un AFN, si deseneaza AFN-ul respectiv.
• va fi necesar sa instalati anumite dependinte pentru a rula scriptul (e.g. networkx, numpy).
• trebuie sa scrieti o procedura de afisare a unui AFN sub forma de CSV. Atasam un exemplu (AFN-ul generat pentru expresia 00*):

from,char,to
0,0,1
1,ε,2
2,ε,3
2,ε,f5
3,0,4
4,ε,3
4,ε,f5

• prima linie este obligatorie si aceeasi pt orice AFN
• tranzitiile sunt codificate pe linii, sub forma: stare initiala, caracter, stare finala
• pentru legibilitate, starile finale au fost precedate de simbolul f
• [TODO: link catre script pe github-ul LFA]

• Folositi clase pentru reprezentarea interna a unei expresii regulate. Vom refolosi aceasta reprezentare in etapa 4.
• Alegeti o implementare pentru AFN-uri care sa permita refolosirea (extinderea) ei pentru situatii in care starile au alta structura. (multimi de intregi in loc de intregi).
• In procesul de parsare, instantiati cu None expresii a caror parsare este in curs de desfasurare. Ele vor fi modificate ulterior.

• In tipul vostru de date care va retine expresii, adaugati constructori pentru expresii a caror parsare este in curs de desfasurare. Acestia vor fi folositi doar in timpul parsarii formei prenex. Spre exemplu, pe langa Concat :: Expr → Expr → Expr, definiti LConcat :: Expr → Expr. Acesta va codifica faptul ca am citit doar partea din stanga a unei concatenari. Asemanator, LRConcat :: Expr va codifica faptul ca am citit o concatenare si urmeaza sa citim operanzii acesteia.
• Interactiunea cu stiva se face cel mai natural folosind pattern matching (si este mult mai simplu de implementat in Haskell).
• Pentru codificarea de NFA-uri:
  • Adaugati clasei FA, definita la etapa anterioara, metoda relabel (si implementati-o):

class FA t where
    fromList :: State s => Set Char -> s -> [(s,Char,s)] -> [s] -> t s
    states :: (State s) => t s -> [s]
    relabel :: (State s, State s') => (s -> s') -> t s -> t s'
    size :: (State s) => t s -> Integer

• Bonus: de ce nu am folosit fmap, in locul functiei relabel?

• Definiti tipul Nfa a si inrolati-l in clasa anterioara. O definitie (mai multe sunt posibile) este urmatoarea:

type NDelta a = Map (a,Char) (Set a)
data Nfa a = Nfa {nsigma :: Set Char, ninitial :: a, ndelta :: (NDelta a), nfin :: [a]}

• construim un fisier mare cu expresii regulate de mana, peste diverse alfabete, care sa acopere cat mai multe din toate situatiile posibile, impreuna cu cuvinte acceptate sau nu. Acest fisier va trebui discutat eventual cu fiecare dintre noi. Exemplu:

  0
  ACCEPT 0
  REJECT 01
  REJECT 10
  
  00*
  ACCEPT 0000000000
  REJECT 1
  REJECT ε
  

• parsam expresiile cu implementarea noastra, generam forma prenex, si creem mai multe perechi de fisiere separate, input-output - in fiecare fisier input se va gasi o expresie si cuvintele de test. Ficare fisier de output va marca rezultatul asteptat. Exemplu:
• Test0.in

  0
  0
  01
  10
 

• Test0.out

 ACCEPT 
 REJECT
 REJECT
 

• Test1.in

  CONCAT 0 STAR 0
  0000000000
  1
  ε
  

• Test1.out

  ACCEPT
  REJECT
  REJECT
  

• Vom verifica, fiecare, ca outputul este corect, folosind implementarile noastre.

Etapa 1 consta in implementarea unui lexer simplu (in Python sau Haskell).

Un lexer este un program care imparte un sir de caractere in subsiruri numite lexeme, fiecare fiind clasificat ca un token. Tabelul de mai jos ilustreaza cateva perechi de tokens si lexeme:

Spre exemplu, sirul x=12+y va fi transformat de lexerul implementat de voi in: (variabila,“x”),(eq,“=”),(valoare,“12”),(plus,“+”),(variabila,“y”).

In realitate, un lexer primeste la input o specificatie de tokens, si produce un program de scanare a inputului care este integrat, intr-o forma sau alta, cu un parser. In aplicatia noastra, lexer-ul va primi doua fisiere:

1. un fisier cu specificatia, descris mai jos.
2. un fisier cu un input (cuvantul) care va fi scanat.

In aceasta etapa, inputul unui lexer va fi conceptual foarte simplu, anume o lista: dfa1, dfa2, … dfan de automate finite deterministe, fiecare codificand un anume token. Mai exact, inputul are urmatoarea structura:

<alfabet>
<dfa1>

<dfa2>

<dfa3>

...

<dfan>

unde:

• <alfabet> este un sir ce codifica alfabetul pentru toate AFD-urile
  • Atentie: un alfabet valid poate contine orice simbol alfanumeric, prin urmare inclusiv SPATII ALBE, care vor fi necesare pt implementarea etapei 4.
• <dfai> este codificarea unui token impreuna cu AFD-ul asociat lui
• codificarea fiecarui AFD se termina printr-o linie goala.

Codificarea unui AFD are urmatoarea structura:

<token>
<stare_initiala>
<tranzitie1>
<tranzitie2>
...
<tranzitie_n>
<stari_finale>

unde:

• <token> este o linie ce contine numele token-ului descris de AFD, deobicei scris cu litere mari (spre exemplu: VARIABILA)
• <stare_initiala> este o linie ce contine un intreg ce desemneaza starea initiala a AFD-ului (deobicei 0)
• <stari_finale> este o linie ce contine o secventa de intregi separati printr-un spatiu alb ce desemneaza starile finale (spre exemplu: 2 3)
• <tranzitie_i> este o linie condifica o tranzitie a AFD-ului, si are urmatoarea forma:
  • <s>,<c>,<d> unde <s> si <d> sunt intregi ce codifica starea sursa respectiv destinatie, iar <c> este un caracter (poate fi orice caracter cu exceptia '\n' si ,

Output-ul se va realiza intr-un fisier si va fi un sir de tokens si lexeme identificate. El va avea forma:

<token1> <lexeme1>
...
<token_n> <lexeme_n>

In linii mari, implementarea unui lexer este relativ simpla: dupa ce a citit lista AFD-urilor (in ordinea din fisier), acesta mentine configuratiile fiecarui AFD pe masura ce scaneaza input-ul. Implementarea lexerului necesita atentie din cauza unei proprietati importante a acestuia:

• el va cauta intotdeauna cel mai lung sir care este acceptat de un AFD

Spre exemplu, daca avem token-urile (definite prin DFA-uri) pentru limbajele:

• ZEROS 0+
• ONES 1+
• PAT 0*10*

si input-ul 00011000, atunci lexer-ul va recunoaste input-ul ca fiind: (PAT,00011000) si nu: (ZEROS,000),(ONES,11),(ZEROS,000).

Pentru a intelege ratiunea acestei abordari, ganditi-va la urmatorul program:

varif = if x > 0 then 1 else 0

Daca token-urile au fost definite corect, programul trebuie sa identifice varif ca fiind o variabla, si nu o variabila urmata de cuvantul cheie if. (Mai multe detalii in Anexa 1).

Tocmai de aceea, in procesul de analiza lexicala, avem nevoie sa determinam, pentru fiecare AFD, multimea sink-states (deobicei, va fi una singura). Aceasta poate fi calculata inversand tranzitiile fiecarui AFD si vizitand toate starile accesibile din starea finala. Starile ce nu vor fi gasite astfel vor fi sink-states.

Spre deosebire de teoria de la curs, unde configuratiile erau perechi cuvant(ramas a fi scanat) si stare, pentru lexerul nostru configuratiile vor fi usor diferite. In primul rand, noi nu verificam daca un AFD accepta un cuvant, ci incercam sa spargem un sir in mai multe cuvinte (de lungime maximala), ce ar fi acceptate de unul din AFD-urile citite de la input.

De aceea, o configuratie pentru un AFD trebuie sa retina (intr-o forma sau alta):

1. starea curenta
2. ultima pozitie din input unde a acceptat (daca este cazul)
3. daca starea curenta este un sink-state sau nu.

Explicam necesitatea lor folosind un exemplu. Sa consideram token-urile (definite ca AFD-uri):

• FST (11)+
• SND (10)+

si input-ul 1011. Lexer-ul va evolua in felul urmator:

• primul caracter: 1. Ambele AFD-uri vor citi 1 si se vor muta in starea succesor, asteptand urmatorul caracter.
• al doilea caracter: 0. AFD-ul aferent FST va ajunge intr-un sink state (odata citit 0 nu mai putem accepta). Al doilea AFD va ajunge intr-o stare finala si in configuratia acestuia vom retine ca la pozitia 1 din sir am identificat un token. Scanarea insa continua, pentru ca acesta nu e in mod necesar cel mai lung lexem aferent token-ului.
• al treilea caracter: 1. AFD-ul aferent FST ramane in sink state. AFD-ul aferent SND ajunge si el in sink-state, si cum nu mai exista alte AFD-uri in stari non-sink, lexer-ul va raporta token-ul avand lexemul cel mai lung care a acceptat anterior, adica cel aferent pozitiei 1: (SND,10).
• reset: procesul de scanare va continua, cu doua modificari:
  • toate AFD-urile vor fi re-aduse in starea initiala
  • ne vom intoarce la input la pozitia urmatoare celei unde am raportat token-ul gasit anterior, adica pozitia 2. Asadar, sirul de la input va fi 11
• revizitam al treilea caracter: 1. Ambele AFD-uri trec intr-o noua stare;
• al patrulea caracter: 0. Al doilea AFD trece intr-un sink state. Primul AFD trece intr-o stare finala. In mod normal, procesul de cautare ar continua, insa intalnim finalul sirului. Prin urmare, raportam (FST,11).

Limbajul Python suporta un mecanism simplu de pattern matching pentru tupluri, care poate fi util in proiect. Ilustram cateva exemple:

def f():
    a,b,c = (1,2,3)
    return a,b,c

print(f()) afiseaza (1,2,3)

def f():
    a,b,*c = (1,2,3)
    return a,b,*c

print(f()) afiseaza (1,2,3)

def f():
    a,b,*c = (1,2)
    return a,b,*c

print(f()) afiseaza (1,2)

Puteti testa voi insiva alte scenarii similare.

Dictionarele din Python vor fi folosite extensiv in proiectul vostru, motiv pentru care este important sa intelegem proprietatea de a fi hashable a cheilor din acestea.

Dictionarele din Python sunt implementate ca HashMaps (tabele de dispersie), in care fiecare element este hashed (dispersat) intr-un bucket (o lista implementata intern), pentru stocare.

• Un hash (functie de dispersie) este cel mai eficient cand se comporta ca o functie injectiva (hash-ul fiecarui element este unic, deci fiecare element are propriul bucket).
• Un hash este corect cand asociaza intotdeauna acelasi hash pentru acelasi element (se comporta ca o functie).

Obiectele mutabile din Python (precum listele, set-urile) nu pot fi folosite drept chei ale unui dictionar, din cauza ca, pe parcursul executiei programului, ele se pot modifica (putem insera un element nou intr-o lista), lucru care ar face ca hash-ul lor sa devina diferit. Prin urmare proprietatea a doua (corectitudinea) nu ar mai fi adevarate.

Putem folosi instante ale claselor drept chei ale dictionarelor, cu conditia sa implementam functia __hash__(). Exista numeroase resurse online despre cum poate fi realizat acest lucru.

In aceasta etapa a proiectului, AFD-urile citite de la input contin stari codificate ca intregi. In implementarea structurii de date care va reprezenta AFD-uri trebuie sa anticipam urmatoarele:

• In alte etape ale proiectului vom folosi AFD-uri in care starile sunt codificate altfel (multimi de intregi).
• De asemenea, vom implementa AFN-uri - o structura de date foarte asemanatoare cu AFD-uri si cu functionalitati comune.
• In cadrul AFN-urilor, starile trebuie sa suporte transformari (sa expuna o functie asemanatoare cu map), care sa nu modifice functionalitatea acestora.

In aceasta etapa a proiectului, puteti: - alege o implementare simpla de AFD (e.g. stari codificate ca intregi impreuna cu un dictionar). Aceasta va trebui sa fie usor de modificat pentru urmatoarele etape a proiectului - pregati o implementare de AFD care sa permita cele de mai sus, si a carei implementare va fi rafinata in urmatoarele etape. Oferim cateva sugestii:

1. implementarea unei clase Stare, care poate fi modificata (sau extinsa) ulterior
2. codificarea starilor printr-o lista: [s1, s2, …, sn], in care elementele pot avea orice tip (profitam astfel de flexibilitatea typing-ului in Python). Dictionarul AFD-ului va folosi indecsii acestei liste si nu valorile efective. In felul asta, putem transforma transparent de dictionar valorile starilor, si evitam problema hashing-ului.

In multe situatii, in implementarea unei operatii generale, avem nevoie de a izola operatii locale, insa acestea au nevoie de intregul context pentru implementare. Spre exemplu:

def smallOperation(x,y,z):
   ...
def tinyOperation(x,y):
   ...
def bigOperation(data1, data2, data3):
    chunk1 = smallOperation(0,data1,data2)
    chunk2 = tinyOperation(data2,data3)
    ...

Puteti evita pasarea contextului global fiecarei operatii, definind functii in functii (suportate in Python). Acestea vor avea vizibil intregul context. Astfel, nu mai mutam date redundant in apeluri de functii, iar codul este mai usor de urmarit:

def bigOperation(data1, data2, data3):
    def smallOperation(x):
       ...
    def tinyOperation():
       ...
    chunk1 = smallOperation(0)
    chunk2 = tinyOperation()
    ...

Pentru a putea integra mai usor lexer-ul vostru cu alte componente pe care le vom implementa ulterior, folositi urmatoarea clasa (la care vom adauga mai tarziu, definitii), care modeleaza Automate Finite (nu neaparat deterministe):

class FA t where
    fromList :: State s => Set Char -> s -> [(s,Char,s)] -> [s] -> t s
    states :: (State s) => t s -> [s]

In anticiparea diverselor transformari care vor fi implementate peste AFD-uri, este important ca starile acestora sa fie polimorfice:

type Delta a = Map (a,Char) a
data Dfa a = Dfa {sigma :: Set Char, initial :: a, delta :: (Delta a), fin :: [a]}

Definitia pentru Delta foloseste Maps care sunt cele mai usor de folosit in acest context.

Inrolati containerul Dfa :: * ⇒ * in clasa FA.

Parcurgerea input-ului linie cu line se implementeaza greoi in Haskell, insa separarea AFD-urilor poate fi realizata usor, plecand de la urmatoarea observatie. Daca impartim folosind caracterul '\n' o portiune din input, vom obtine:

[ <linie1>, ... <linie_k>, "", <linie_k+1> , .... <linie_k+n>, "", ...]

Daca aplicam aceeasi functie de impartire (cu signatura rescrisa polimorfic) folosind obiectul “”, obtinem o lista de liste de linii, unde fiecare lista de linii reprezinta codificarea unui AFD.

Signaturile functiilor voastre pot deveni lungi. Va recomandam sa le scrieti voi insiva (va ajuta la implementarea corecta), si sa introduceti, de fiecare data cand simtiti nevoia, type-def-uri menite sa faca citirea codului mai usoara. Exemplu:

type Index = Integer
type State = Integer
 
f :: State -> Index -> ...
f = ...

Cautati sa evitati implementarile mamut in detrimentul izolarii functionalitatii in functii simple, cu signaturi scrise de voi, si cu comentarii intuitive. De multe ori, functiile pot fi atat de scurte, incat pot fi scrise inline. Va incurajam sa folositi $ impreuna cu . si sa formatati cat mai intuitiv codul.

Exemplu negativ:

f l = zipWith (\x y-> (x:y)) (head (take 20 ((reverse (tail l)))) (tail (reverse l))

Exemplu pozitiv:

f l = zipWith (:) l1 l2
       where l1 = head           -- i am extracting the first element of the list because... 
                   $ (take 20)   -- i only take the first 20 elements because ...
                   $ reverse     -- the list must be reversed
                   $ tail l
             l2 = (tail . reverse) l -- i am composing two transformations over l

• Vizitati functiile din biblioteca Data.Map si Data.Set. Unele pot fi foarte utile pentru implementare
• Refolositi functia splitBy de la PP
• Aruncati o privire peste functia sortOn. Este mai simplu de folosit si mai performanta decat sortBy.
• Aruncati o privire peste list comprehensions. Pot fi utile local.

Cel mai probabil, la baza implementarii voastra va sta o functie de forma:

lexer :: InputString -> [TokensAndTheirDfas] -> Output

care va fi tail-recursive, si la tipul careia veti adauga diverse alte componente/acumulatori. Debugging-ul acesteia poate fi dificil, in special daca functia cicleaza. O modalitate simpla de debugging este sa adaugati functiei voastre doua variabile, modificand output-ul astfel:

auxLexer :: InputString -> [TokensAndTheirDfas] -> String -> Integer -> (String,Output)
auxLexer _ _ _ 100 = ...

unde:

• variabila de tip String va codifica elemente de logging utile pentru debugging (e.g. starea sirului, starile curente ale AFD-urilor). La fiecare apel recursiv puteti adauga informatii la logging pentru a urmari mai usor executia functiei. La final, puteti intoarce informatiile de logging, impreuna cu outputul.
• variabila de tip Integer va reprezenta numarul de apeluri recursive. Cand o limita (hardcodata) este atinsa, functia intoarce indiferent de valoarea parametrilor. In felul asta, puteti inspecta logging-ul si in situatia cand functia cicleaza. Nu uitati sa incrementati la fiecare apel recursiv variabila in cauza.
• puteti pastra aceasta forma si in implementarea voastra finala ( imbracand functia auxLexer cu o alta functie care ascunde detaliile de logging)

Revenind la exemplul anterior, am putea incerca sa rezolvam problema identificarii folosind ordinea in care sunt definite tokens. Observati insa ca, in acest exemplu, nici o ordine a tokenilor pentru variabila si if nu ne vor ajuta sa scanam corect inputul (daca regula pentru if e prioritara, se repeta situatia descrisa anterior, iar daca regula pentru variabile e prioritara, if va fi scanat ca o variabila (probabil functie).

varif = if x > 0 then 1 else 0