Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
lfa:2025:proiect:etapa2 [2025/11/20 11:57]
pdmatei
lfa:2025:proiect:etapa2 [2025/11/25 20:48] (current)
ldaniel
Line 1: Line 1:
 Deadline etapa 1: 26 nov 2025 23:55 Deadline etapa 1: 26 nov 2025 23:55
  
-Deadline etapa 2: ian 2026 23:55+Deadline etapa 2: 16 ian 2026 23:55
  
 Link etapa 1 [[lfa:​2025:​proiect:​etapa1| Etapa 1]] Link etapa 1 [[lfa:​2025:​proiect:​etapa1| Etapa 1]]
  
 +Schelet de cod: {{:​lfa:​2025:​proiect:​lfa2025_skel_etapa2.zip|}}
  
-===== Etapa 2 =====+ 
 +====== Etapa 2 ======
  
 **Etapa 2** a proiectul consta in implementarea unui Lexer in Python si, pe baza acestuia, implementarea unui Parser elementar pentru expresii lambda. **Etapa 2** a proiectul consta in implementarea unui Lexer in Python si, pe baza acestuia, implementarea unui Parser elementar pentru expresii lambda.
Line 13: Line 15:
  
  
-=== Ce este un Lexer ===+===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. 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. 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.
  
Line 68: Line 70:
  
  
-=== Parser ===+==== Parser ​====
  
 Un parser foloseste output-ul produs de lexer pentru etapa de analiza sintactica a textului. ​ Un parser foloseste output-ul produs de lexer pentru etapa de analiza sintactica a textului. ​
  
-Construim un parser pe baza unei gramatici care contine reguli ce descriu sintaxa valida a inputului. O astfel de gramatica va folosi ​lexemele ​generate de analiza lexicala in rolul de terminali.+Construim un parser pe baza unei gramatici care contine reguli ce descriu sintaxa valida a inputului. O astfel de gramatica va folosi ​categoriile lexicale ​generate de analiza lexicala in rolul de terminali.
  
-<<MP: explica sintaxa gramaticilor in implementarea noastra, inaintea exemplului, pt ca nu are sens regula din gramatica. Inlocuieste 3 cu 1 + 2, si elaboreaza pe exemplu. Spune aici ca toate gramaticile noastre sunt FNC>>+=== Sintaxa pentru gramatici ===
  
-Exemplu: pentru textul "int x = 3" analiza lexicala produce {(TYPE, "​int"​),​ (ID, "​x"​),​ (EQUAL, "​="​),​ (NUMBER"​3"​)}. ​ si o gramatica ​pentru ​aceasta expresie de atribuire:+In implementarea noastrasintaxa folosita ​pentru ​descrierea gramaticilor in format text va fi urmatoarea:
 <​code>​ <​code>​
- ​assignTYPE ID EQUAL NUMBER+sa b 
 +s: b a 
 +a: A 
 +b: B
 </​code>​ </​code>​
 +unde a si b sunt neterminali si A si B sunt terminali. Preferam sa notam neterminalii cu litere mici si terminalii cu litere mari deoarece terminalii nostri vor fi tokenii proveniti de la analiza lexicala. De asemenea, putem scrie simplificat primele 2 reguli astfel, folosind o alternativa:​
 +<​code>​
 +s: a b|b a
 +</​code>​
 +E important ca inainte si dupa simbolul pentru alternativa sa nu existe spatii, pentru citirea corecta a fisierului. In mod automat simbolul care introduce prima regula din gramatica este considerat simbolul de start, indiferent de denumirea lui.
 +
 +Gramaticile folosite de noi vor fi intotdeauna in Forma Normala Chomsky, pentru a putea aplica algoritmul care valideaza apartenenta unui cuvant la limbajul generat de gramatica.
 +
 +O gramatica este in FNC daca are doar reguli de tipul a: b c (un neterminal produce doi neterminali) sau a: A (un neterminal produce un singur terminal).
 + 
 +
 +=== Verificarea acceptarii unui cuvant de catre gramatica ===
 +
 +Pentru a verifica daca un cuvant apartine limbajului descris de o gramatica in FNC folosim algoritmul CYK.
 +Algoritmul CYK poate fi consultat in materialele de la curs. 
 +
 +=== Arbore de parsare ===
 +
 +In plus fata de algoritmul CYK implementat la curs, care ne spune daca un text este acceptat de gramatica, ne dorim sa avem si secventa de derivari care a produs cuvantul, sau echivalent: arborele de parsare pentru textul nostru. In scheletul temei aveti implementata o clasa numita ParseTree, care reprezinta arborele de parsare.
  
-<<MP: se muta mai sus>> O gramatica este in FNC daca are doar reguli ​de tipul A: B C (un neterminal produce doi neterminali) sau A: a (un neterminal produce un singur terminal)+Arborele ​de parsare va fi afisat ca un arbore in care copiii au o indentare cu 2 spatii mai la dreapta decat parintele
  
-Algoritmul CYK poate fi consultat in materialele de la curs. (hint pentru implementare:​ folositi ​matrice ​de dictionare in care pentru ​fiecare neterminal aveti ca valoare un nod de parseTree ca la final sa obtinem arborele de parsare). +Atunci cand doreste sa foloseasca ​gramatica independenta ​de context arbitrara ​pentru parsare, programatorul trebuie intai sa o converteasca (manualin FNCPentru ​usura vizualizarea arborilor ​de parsare, ​convenim sa denumim toti non-terminalii creati ​in procesul ​de conversie cu **int_**. Vom folosi aceasta conventie pentru a nu afisa regulile ce au in stanga ​un non-terminal de forma **int_**, ci direct copii. Astfel, arborii ​de parsare ​sunt mai usor de citit. Pentru regulile simplede tipul neterminal produce un terminal (a: TOKEN) se va afisa doar categoria lexicala si lexemul corespunzator,​ fara numele reguliiAceste lucruri sunt deja implementate in metoda str() a lui ParseTree.
-<<MP: nu s-mentionat nicaieri despre arbore ​de parsare. Scrie aici ca, in plus fata de algoritmul prezentat la curs, implementarea lor trebuie sa construiasca si un arbore ​de parsare, ​nu doar sa verifice ca sirul e valid c.f. gramaticii.>>+
  
-Dupa aplicarea etapei de parsare se obtine un arbore de parsare. ​+Pentru a obtine un arbore de parsare ​ca rezultat, in implementarea algoritmului CYK va recomandam sa folositi o matrice de dictionare in care pentru fiecare neterminal sa aveti ca valoare un ParseTree cu informatiile despre derivarile bottom-up care au dus la obtinerea acelui neterminal. La final, in caz de acceptare, arborele de parsare afisat va fi arborele avand ca radacina simbolul de start.
  
-Cerinta:+=== Cerinta: ​===
 Implementati un parser general, care primeste o gramatica in FNC si returneaza un arbore de parsare. Implementati un parser general, care primeste o gramatica in FNC si returneaza un arbore de parsare.
  
-In clasa Grammar completati metoda "​cykParse",​ care primeste output-ul unui lexer (tupluri de (token, lexema)) si intoarce arborele de parsare.+1. In clasa Grammar completati metoda "​cykParse",​ care primeste output-ul unui lexer (tupluri de (token, lexema)) si intoarce arborele de parsare.
  
-Scrieti o gramatica in FNC in fisierul "​grammar_lambda.txt",​ pornind de la gramatica din fisierul "grammar.txt". Aplicati voi transformarile prezentate la curs pentru a obtine FNC. Toti neterminalii creati in acest proces trebuie sa inceapa cu+2. Scrieti o gramatica in FNC in fisierul "**grammar_lambda.txt**", pornind de la gramatica ​pentru expresii lambda ​din fisierul "**parser_grammar.txt**". Aplicati voi transformarile prezentate la curs pentru a obtine FNC. Toti neterminalii creati in acest proces trebuie sa inceapa cu
 "​int_",​ pentru a fi distinsi de ceilalti neterminali,​ astfel incat sa ii omitem cand afisam arborele de parsare. Astfel outputul este mult mai usor de urmarit. "​int_",​ pentru a fi distinsi de ceilalti neterminali,​ astfel incat sa ii omitem cand afisam arborele de parsare. Astfel outputul este mult mai usor de urmarit.
  
-In clasa Parser completati metoda ​"parse", pentru ​a scrie un parser general care citeste o gramatica in FNC din fisierul primit ca parametru la initializare si returneaza arborele de parsare.+3. Completati specificatia pentru Lexerul de expresii lambda in fisierul ​"**lexer_spec.json**", ​adaugand regex-ul potrivit ​pentru ​fiecare Token.
  
-Clasa ParseTree este implementata deja.+4. In clasa Parser completati metoda "​parse",​ care primeste un text de intrare si returneaza arborele de parsare. Folositi-va de campurile lexer si grammar ale parserului pentru analiza lexicala si apoi analiza sintactica a textului. Dupa analiza lexicala va trebui sa ignoratii tokenii SPACE inainte de a trece la analiza sintactica.
  
  
-Fiind data urmatoarea gramatica pentru expresii lambda ​(din Lambda Calculus), scrieti o gramatica ​in FNC pe care sa o folositi ​in clasa Parser:+=== Exemplu de parsare === 
 +Pentru textul "int x = 1 + 2" analiza lexicala a produs tokenii [(TYPE, "​int"​), (ID, "​x"​),​ (EQUAL, "​="​),​ (NUMBER, "​3"​),​ (PLUS, "​+"​),​ (NUMBER, "​2"​)] (tokenii SPACE au fost ignorati). 
 + 
 +Parserul e configurat cu urmatoarea ​gramatica ​(care in exemplu nu e in FNC, dar inainte de a fi interpretata de Parser ​a fost convertita la FNC):
 <​code>​ <​code>​
-<​e> ​::= <var> | '​('​ <e> '​)'​ | <e> <op> <e> | '​\'<​var>​.<​e>​ + ​assignTYPE ID EQUAL sum 
-<op> ::= (+|-|/) + sumNUMBER PLUS NUMBER
-<var> ::= [a-zA-Z0-9]++
 </​code>​ </​code>​
  
-=== Exemplu === +Arborele de parsare obtinut va fi:
 <​code>​ <​code>​
-\x.(x * (x + 2)-> Lambda ​(var "​x"​-> Mul (var "​x"​) (Parant (Plus (var "​x"​) (val 2)))+assign 
 +  ​(TYPE: int) 
 +  ​(ID: x) 
 +  ​(EQUAL: =) 
 +  sum 
 +    ​(NUMBER: 1) 
 +    ​(PLUS: +) 
 +    ​(NUMBER: ​2)
 </​code>​ </​code>​
- 
-<note important>​ 
-Pentru moment, exista doar testele pentru lexer! 
-Zilele acestea vor aparea si cateva teste pentru parser 
-</​note>​ 
- 
  
  
Line 124: Line 149:
  
 Verificarea corectitudinii implementarii voastre se va face automat, printr-o serie de teste unitare, teste care vor verifica comportamentul fiecarei functii obligatorii de implementat si ii va testa output-ul pe o diversitate de input-uri. Verificarea corectitudinii implementarii voastre se va face automat, printr-o serie de teste unitare, teste care vor verifica comportamentul fiecarei functii obligatorii de implementat si ii va testa output-ul pe o diversitate de input-uri.
- 
-<<MP: nu inteleg despre ce DFA construit e vorba>>​ 
-O alta verificare preliminara care se va face pe fiecare DFA construit va fi unul care verifica integritatea lui d.p.d.v. structural (starea initiala si starile finale sunt incluse in multima de stari, nu are tranzitii definite pe un caracter dintr-o anume stare). 
  
 ==== Python ==== ==== Python ====
Line 147: Line 169:
 <​code>​ <​code>​
 . .
-── src +├── grammar_lambda.txt 
-    ├── __init__.py +├── lexer_spec.json 
-    ├── DFA.py +── src 
-    ├── NFA.py +│   ​├── __init__.py 
-    ├── Regex.py +│   ​├── DFA.py 
-    ├── Lexer.py +│   ​├── NFA.py 
-    ├── Parser.py +│   ​├── Regex.py 
-    ... (alte surse pe care le folositi)+│   ​├── Lexer.py 
 +│   ​├── Parser.py 
 +│   ├── Grammar.py 
 +│   ├── ParseTree.py 
 +|   ... (alte surse pe care le folositi)
 ├── ID.txt ├── ID.txt
 </​code>​ </​code>​