Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
lfa:2022:proiect-wip [2022/10/31 10:36] pdmatei |
lfa:2022:proiect-wip [2022/10/31 14:10] (current) mihai.udubasa [Forma Prenex a expresiilor regulate] fix second-to-last example to be more clear |
||
---|---|---|---|
Line 7: | Line 7: | ||
===== Ce este un lexer? ==== | ===== Ce este un lexer? ==== | ||
- | Un lexer este un program care imparte un sir de caractere in subsiruri numite *lexeme*, fiecare dintre acestea fiind clasificat ca un *token*, pe baza unei specificatii. | + | Un lexer este un program care imparte un sir de caractere in subsiruri numite //lexeme//, fiecare dintre acestea fiind clasificat ca un //token//, pe baza unei specificatii. |
==== Care este input-ul unui lexer? ==== | ==== Care este input-ul unui lexer? ==== | ||
Line 67: | Line 67: | ||
* ''STAR UNION CONCAT a b CONCAT b STAR d'', echivalent cu $math[( (ab) \cup ( b(d^*) ) )^*] | * ''STAR UNION CONCAT a b CONCAT b STAR d'', echivalent cu $math[( (ab) \cup ( b(d^*) ) )^*] | ||
- | * ''CONCAT PLUS c UNION a PLUS b'', echivalent cu $math[c^+( a| (b^+) )] | + | * ''CONCAT PLUS c UNION a PLUS b'', echivalent cu $math[c^+( a \cup (b^+) )] |
- | * ''UNION ' ' '@' ''; ''STAR '#' '' | + | * ''UNION ' ' '@%%'%%'', accepta limbajul { '' '' , ''@'' } |
- | * ''UNION eps a'', ''MAYBE a'', echivalente cu ''a\cup ε'' | + | * ''UNION eps a'', ''MAYBE a'', echivalente cu $ma |
+ | th[a\cup \epsilon] | ||
* ''void'' | * ''void'' | ||
Line 77: | Line 78: | ||
===== Implementare ===== | ===== Implementare ===== | ||
- | Pentru implementarea acestei etape, se va implementa parsarea expresiei prenex (se recomanda folosirea unei structuri interne arborescente ca rezultat al parsarii, dar reprezentarea exacta a acestei structuri este la latitudinea voastra) si conversiile Prenex -> AFN -> AFD, pentru care se vor folosi algoritmii discutati la curs. | + | Implementarea consta in parsarea expresiei prenex (se recomanda folosirea unei structuri interne arborescente (AST - Abstract Syntax Tree) ca rezultat al parsarii, dar reprezentarea exacta a acestei structuri este la latitudinea voastra) si conversiile Prenex -> AFN -> AFD, pentru care se vor folosi algoritmii discutati la curs. |
===== Reprezentarea starilor automatelor ===== | ===== Reprezentarea starilor automatelor ===== | ||
- | Desi cea mai simpla modalitate de a ne referi la o stare este printr-un numar intreg, in anumite componente ale proiectului (si de la aceasta etapa, dar si de la etape viitoare) va fi mult mai convenabil sa lucram cu alte tipuri de etichete pentru stari (de exemplu, seturi de intregi sau tupluri). De aceea, implementarea claselor DFA si NFA trebuie sa fie generica in raport cu tipul de date prin care reprezentam starile. | + | Desi cea mai simpla modalitate de a ne referi la o stare este printr-un numar intreg, in anumite componente ale proiectului (si de la aceasta etapa, dar si de la etape viitoare) va fi mult mai convenabil sa lucram cu alte tipuri de etichete pentru stari (de exemplu, seturi de intregi sau tupluri). De aceea, este indicat ca implementarea claselor DFA si NFA trebuie sa fie **generice (polimorfice)** in raport cu tipul de date prin care reprezentam starile. |
- | In plus, in anumite momente este foarte posibl sa fie nevoie sa redenumim starile unui anumit automat. In acest caz, este recomandata implementarea unei functionalitati de tip `map` care sa faca aceasta redenumire dupa o anumita functie (primita ca parametru), fara a modifica comportamentul automatului. | + | De asemenea, in mai multe etape ale proiectului va fi necesar sa modificam, in diverse feluri, reprezentarea starilor. Vom realiza acest lucru in cel mai general mod posibil, implementand ''map'' (putem spune ca AFD-urile si AFN-urile sunt //functori//). Este esential ca implementarea lui ''map'' sa nu modifice in vreun fel //comportamentul// automatului (adica limbajul acceptat de acesta). |
- | + | ||
- | ===== Parsarea expresiilor prenex ===== | + | |
+ | ===== Parsarea expresiilor prenex ===== | ||
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: | 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: | ||
Line 104: | Line 104: | ||
Aceste teste nu acopera fiecare caz posibil si testeaza doar comportarea corecta a AFD-urilor si AFN-urilor obtinute din cateva expresii in forma prenex, pe cateva secvente reprezentative. | Aceste teste nu acopera fiecare caz posibil si testeaza doar comportarea corecta a AFD-urilor si AFN-urilor obtinute din cateva expresii in forma prenex, pe cateva secvente reprezentative. | ||
- | Sunteti incurajati sa va adaugati propriile teste, fie pentru a asigura corectitudinea pe mai multe cazuri sau pentru a testa alte componente intermediare (de exemplu parsarea corecta a expresiilor in forma prenex si construirea unui arbore corect pentru acestea). | + | **Sunteti incurajati sa va adaugati propriile teste**: |
+ | - pentru a asigura corectitudinea pe mai multe cazuri simple sau intermediare | ||
+ | - pentru a testa alte componente intermediare ale codului vostru (de exemplu parsarea corecta a expresiilor in forma prenex si construirea unui arbore corect pentru acestea). | ||
+ | |||
+ | **O abordare eficienta, economica dpdv al timpului, de scris cod poate fi sumarizata astfel:** | ||
+ | - scriem un test pentru o functie/componenta noua, sau o parte bine determinata a acesteia (e.g. parsarea corecta a reuniunii a doua regexuri) | ||
+ | - scriem implementarea pentru acea componenta | ||
+ | - folosim eventuale afisari **doar** pentru debugging, atunci cand nu este evident de ce un test pica | ||
+ | - cand un test trece, trecem la urmatoarea componenta | ||
+ | - cand e necesar sa modificam componente la care am lucrat anterior, re-rulam toate testele anterioare, pentru a ne asigura ca modificarea nu a afectat corectitudinea codului | ||
<note> | <note> | ||
- | Folderul care contine testele va fi suprascris de checker, testele luate in considerare fiind cele din skeletul de cod | + | Folderul care contine testele va fi suprascris de checker, testele luate in considerare pentru nota fiind doar cele din skeletul de cod. |
</note> | </note> | ||
Line 124: | Line 133: | ||
==== Scala ==== | ==== Scala ==== | ||
- | Pentru rularea testelor folositi comanda ''sbt test''. | + | Pentru rularea testelor, puteti folosi interfata pusa la dispozitie de IntellIJ. |
+ | Daca folositi doar command-line, folositi comanda ''sbt test''. | ||
Aceasta comanda va rula testele definite in folderul ''src/test/scala'' si va afisa cu verde testele terminate cu succes si cu rosu testele esuate. | Aceasta comanda va rula testele definite in folderul ''src/test/scala'' si va afisa cu verde testele terminate cu succes si cu rosu testele esuate. | ||
Line 142: | Line 152: | ||
<note important> | <note important> | ||
In radacina proiectului trebuie pus un fisier intitulat ''ID.txt'' | In radacina proiectului trebuie pus un fisier intitulat ''ID.txt'' | ||
- | ce va avea pe prima linie a sa ID-ul vostru anonim (ar trebui sa il fi primit pe mail, dar daca din vreun motiv nu il aveti, vorbiti cu asistenul de laborator) si pe a doua linie limbajul in care rezolvati tema (''python'' sau ''scala'') | + | ce va avea pe prima linie a sa ID-ul vostru anonim (ar trebui sa il fi primit pe mail, dar daca din vreun motiv nu il aveti, luati legatura cu asistentul vostru) si pe a doua linie limbajul in care rezolvati tema (''python'' sau ''scala'') |
- | De exemplu: | + | Exemplu de continut pentru ''ID.txt'': |
<code> | <code> | ||
9921225 | 9921225 |