Checker si teste: Checker proiect LFA.
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:
Token | Lexeme |
---|---|
variabla | x |
variabla | var |
valoare | 23 |
plus | + |
eq | = |
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:
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:
<dfa1> <dfa2> <dfa3> ... <dfan>
unde:
<dfai>
este codificarea unui token impreuna cu AFD-ul asociat luiCodificarea unui AFD are urmatoarea structura:
<alphabet> <token> <stare_initiala> <tranzitie1> <tranzitie2> ... <tranzitie_n> <stari_finale>
unde:
<alfabet>
este un sir ce codifica alfabetul pentru AFD-ul aferent<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 (deo bicei 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 ,
)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:
Spre exemplu, daca avem token-urile (definite prin DFA-uri) pentru limbajele:
0+
1+
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):
Explicam necesitatea lor folosind un exemplu. Sa consideram token-urile (definite ca AFD-uri):
(11)+
(10)+
si input-ul 1011
. Lexer-ul va evolua in felul urmator:
1
. Ambele AFD-uri vor citi 1
si se vor muta in starea succesor, asteptand urmatorul 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.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)
. 11
1
. Ambele AFD-uri trec intr-o noua stare;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. Mai multe detalii despre hashing si dictionare gasiti aici.
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:
map
), care sa nu modifice functionalitatea acestora.In aceasta etapa a proiectului, puteti:
Stare
, care poate fi modificata (sau extinsa) ulterior[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 valorile starilor transparent fata de dictionar, si astfel sa 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
Data.Map
si Data.Set
. Unele pot fi foarte utile pentru implementaresplitBy
de la PP.sortOn
. Este mai simplu de folosit si mai performanta decat sortBy
.Data.Maybe
si Data.Either
, ar putea fi utile in anumite contexte.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:
auxLexer
cu o alta functie care ascunde detaliile de logging)