Differences

This shows you the differences between two versions of the page.

--- lfa:2024:proiect:etapa3 [2024/12/12 12:46]
atoader
+++ lfa:2024:proiect:etapa3 [2024/12/13 17:01] (current)
atoader
@@ Line 3: / Line 3: @@
 Deadline etapa 2: 9 dec 2024 23:55
-Deadline etapa 3: TBD
+Deadline etapa 3: 12 ian 2025 23:55
 Schelet etapa 1 {{:lfa:2023:lfa2024-skel-etapa1.zip|}}
@@ Line 13: / Line 13: @@
 ===== Etapa 3 =====
-**Etapa 3** a proiectul consta in implementarea unui lexer in python si, folosindu-va de lexer, implementarea unui parser elementar pentru expresii lambda.
+**Etapa 3** a proiectul consta in implementarea unui lexer in python si, pe baza acestuia, implementarea unui parser elementar pentru expresii lambda.
 === 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. Specificatia contine o secventa de perechi $math[(token_i, regex_i)] in care fiecare token este descris printr-o expresie regulata. Ordinea perechilor in secventa este importanta, iar acest aspect va fi discutat ulterior.
-Exista mai multe modalitati prin care puteti implementa un lexer. Abordarea conventionala (si cea pe care o recomandam) consta in urmatoarele etape:
+Exista mai multe modalitati prin care un lexer poate fi implementat. Abordarea conventionala (si cea pe care o recomandam) consta in urmatorii pasi:
-  - fiecare regex este convertit intr-un AFN, pastrand totodata informatia despre token-ul aferent si pozitia la care acesta apare in spec.
+  - fiecare regex este **convertit intr-un AFN**, retinand in acelasi timp token-ul pe care il descrie precum si pozitia in care acesta apare in secventa.
-  - se construieste un AFN unic, introducand o stare initiala si epsilon-tranzitii de la aceasta catre toate starile initiale ale AFN-urilor de mai sus. Astfel, acest AFN va accepta oricare dintre tokenii descrisi in specificatie. Starea finala vizitata va indica token-ul gasit.
+  - **se construieste un AFN unic**, introducand o stare initiala si epsilon-tranzitii de la aceasta catre toate starile initiale ale AFN-urilor de mai sus. Astfel, acest AFN va accepta oricare dintre tokenii descrisi in specificatie. Fiecare stare finala din AFN-ul unic va indica token-ul corespunzator gasit.
   - AFN-ul este convertit la un AFD (care optional poate fi minimizat). In acest automat:
      - cand vizitam un grup de stari ce contine (AFN-)stari finale, inseamna ca unul sau mai multe token-uri corespunzatoare au fost identificate.
-     - cand vizitam un sink-state (daca acesta exista), inseamna ca subsirul curent nu este descris de nici un token. In acest caz trebuie sa intoarcem cel mai lung prefix acceptat si sa continuam lexarea cuvantului ramas
+     - cand vizitam un sink-state (daca acesta exista), inseamna ca subsirul curent nu este descris de nici un token.
-     - cand vizitam o stare non-finala si care nu e sink-state, continuam prin trecerea in urmatoarea stare a AFD-ului consumand un caracter din cuvant
-Scopul unui lexer este identificarea **celui mai lung subsir** care satisface un regex din specificatia data. Daca un cel mai lung subsir satisface **doua sau mai multe regex-uri**, va fi raportat primul token aferent, in ordinea in care acestea sunt scrise in specificatie.
+Pentru ca analiza lexicala sa poata functiona corect, AFD-ul descris anterior este folosit pentru a identifica, la fiecare pas, **cel mai lung subsir** din sirul analizat, care e generat de un regex. In situatia in care un astfel de subsir e generat de doua sau mai multe regex-uri, va fi raportat primul token aferent, in raport cu ordinea din specificatie.
-Pentru a identifica **cel mai lung subsir** folosind un AFD precum cel descris in sectiunea anterioara, trebuie sa observam faptul ca:
+Pentru a identifica **cel mai lung subsir** folosind un AFD precum cel descris in sectiunea anterioara, trebuie sa observam faptul ca, daca ne aflam la pozitia $math[i] in sirul $math[w] de la input si:
-  - vizitarea unui grup de stari ce contine o (AFN-)stare finala, **nu indica** in mod necesar faptul ca am gasit cel mai lung subsir acceptat.
+  - ne aflam intr-un grup de stari ce contine o (AFN-)stare finala, atunci $math[w(0,i)] **nu este in mod necesar** cel mai lung subsir
-  - daca un grup de stari ce contine o (AFN-)stare finala a fost vizitata **anterior**:
+  - daca ne aflam in sink-state-ul AFD-ului inseamna ca un subsir de lungime mai mare ca $math[i] nu poate exista. In acelasi timp, cel mai lung subsir este cel mai lung cuvant $math[w(0,j)] cu $math[j<i], daca acesta a fost acceptat anterior, in cazul in care un astfel de cuvant exista.
-    - vizitarea unui grup de stari ce nu contine stari finale, **nu indica** in mod necesar faptul ca am gasit cel mai lung subsir (automatul poate accepta in viitor)
+  - daca in AFD nu exista un sink state, atunci analiza lexicala trebuie sa continue pana la epuizarea inputului, pentru a decide asupra celui mai lung subsir.
-    - vizitarea sink-state-ului AFD-ului (daca acesta exista), indica faptul ca automatul nu va mai accepta in viitor.
-    - daca in AFD nu exista un sink state, atunci analiza lexicala trebuie sa continue pana la epuizarea inputului, pentru a decide asupra celui mai lung subsir.
 Odata ce subsirul cel mai lung a fost identificat:
@@ Line 47: / Line 44: @@
 unde primul element din fiecare tuplu este un nume dat unui token, iar al doilea element din tuplu este un regex ce descrie acel token. Puteti imagina aceasta specificatie ca un //fisier de configurare// care descrie modul in care va functiona lexerul pe diverse fisiere de text.
-In plus, clasa lexer contine functia ''lex'' care va primi un cuvant ''str'' ca input si va intoarce rezultatul lexarii lui sub forma ''list[tuple[str, str]]''. Metoda va intoarce o lista de tupluri ''(token, lexem_cuvant)'' in cazul in care lexarea reuseste. In caz de eroare, se va intoarce o lista cu un singur element de forma ''("", "No viable alternative at character _, line _")'' (//Mai multe despre cazurile in care un lexer poate esua mai jos//). Astfel, metoda are ca output o lista de forma : ''[(TOKEN_LEXEMA_1, lexema1), (TOKEN_LEXEMA_2, lexema2), ...]'', unde ''TOKEN_LEXEMA_N'' este numele token-ului asociat lexemei n, pe baza specificatiei.
+In plus, clasa lexer contine functia ''lex'' care va primi un cuvant ''str'' ca input si va intoarce rezultatul analizei lexicale sub forma ''list[tuple[str, str]]''. Metoda va intoarce o lista de tupluri ''(token, lexem_cuvant)'' in cazul in care analiza reuseste. In caz de eroare, se va intoarce o lista cu un singur element de forma ''("", "No viable alternative at character _, line _")'' (//Mai multe despre cazurile in care un lexer poate esua mai jos//). Astfel, metoda are ca output o lista de forma : ''[(TOKEN_LEXEMA_1, lexema1), (TOKEN_LEXEMA_2, lexema2), ...]'', unde ''TOKEN_LEXEMA_N'' este numele token-ului asociat lexemei n, pe baza specificatiei.
 === Exemplu ===
@@ Line 61: / Line 58: @@
 === Erori de lexare ===
-Erorile de lexare sunt in general cauzate o configuratie gresita / incompleta sau de un cuvant invalid. Informatiile care trebuie transmise in acest caz trebuie sa ajute programatorul sa isi dea seama unde un cod s-a intamplat eroarea si care este tipul erorii. Din acest motiv vom afisa linia si coloana unde lexarea a esuat si tipul erorii. Eroarea este echivalenta cu ajungerea in starea ''SINK_STATE'' a lexerului fara a trece in prealabil printr-o stare finala. In acest caz vom afisa un mesaj de eroare in formatul
+Erorile de lexare sunt in general cauzate o configuratie gresita / incompleta sau de un cuvant invalid. Informatiile care trebuie transmise in acest caz trebuie sa ajute programatorul sa isi dea seama unde un cod s-a intamplat eroarea si care este tipul erorii. Din acest motiv vom afisa linia si coloana unde analiza lexicala a esuat si tipul erorii. Eroarea este echivalenta cu starea curenta: ''SINK_STATE'' a lexerului fara a trece in prealabil printr-o stare finala. In acest caz vom afisa un mesaj de eroare in formatul
   No viable alternative at character ..., line ...
-In primul loc liber vom pune indexul caracterului unde s-a oprit lexarea (am ajuns in ''SINK_STATE'') indexat de la 0, iar in an doilea spatiu liber vom pune linia unde s-a intamplat asta (indexata de la 0).
+In primul loc liber vom pune indexul caracterului unde s-a oprit analiza (am ajuns in ''SINK_STATE'') indexat de la 0, iar in an doilea spatiu liber vom pune linia unde s-a intamplat asta (indexata de la 0).
-Daca lexarea a ajuns la finalul cuvantului fara a accepta in prealabil un lexem, iar lexerul nu a ajuns in sink state, insa nici intr-o stare finala, vom afisa un mesaj de eroare in formatul:
+Daca analiza a ajuns la finalul cuvantului fara a accepta in prealabil o lexema, iar lexerul nu a ajuns in sink state, insa nici intr-o stare finala, vom afisa un mesaj de eroare in formatul:
   No viable alternative at character EOF, line ...