boozec / clp Goto Github PK

Quando si prova a stampare l'ast di un codice come, ad esempio:

m = 1
for i in range(10):
    m = m + 1

L'ast del blocco del for viene stampato come:

Block
  SimpleStmts
    SimpleStmt
      Assignment
        ExprList
          Expr
            Atom(m)
          Augassign(=)
          ExprList
            Expr
              Atom(1)
            Op(+)

Ovvero, mostra solo il primo elemento dell' ExprList a destra dell'assegnamento (a questo punto probabilmente stampa sempre e solo il primo elemento in ogni caso).

Sono presenti due offset:

• Uno generale dentro semanticanalysis.SymbolTable che corrisponde ad una lista di offset dove ogni indice è uno scope diverso.
• Uno più specifico dentro semanticanalysis.STentry che corrisponde all'offset utilizzato da una singola variabile.

Bisognerebbe valutare quale dei due ritorna più utile durante l'analisi semantica ed eventualmente si potrebbe rimuovere l'altro.

Eseguire il file Main.java con un parametro che corrisponde al file Python da testare.

Ci sono assegnamenti del tipo:
(left, right) = (1, 2)

e for del tipo:
for k,v in t.items():

Attualmente non controlliamo questi assegnamenti e abbiamo commentato tutti i codici che li presentano, sarebbero da gestire per fare le cose pulite o da ignorare se ci bastano tutti i codici che parsiamo.

Ci sarebbe da aggiungere i test puliti tipo JUnit

Nel file Python3VisitorImpl.java vi è questo Tlc. Ora, dato che attualmente fanno la medesima cosa, perché non modificare questo
sotto

        } else if (ctx.OPEN_BRACE() != null && ctx.CLOSE_BRACE() != null) {
            return manageTlc(tlc);
        } else if (ctx.OPEN_BRACK() != null && ctx.CLOSE_BRACK() != null) {
            return manageTlc(tlc);
        } else if (ctx.OPEN_PAREN() != null && ctx.CLOSE_PAREN() != null) {
            return manageTlc(tlc);
        }
        return new AtomNode(null, null);
    }

    public AtomNode manageTlc(Testlist_compContext tlc) {
        if (tlc != null) {
            Node testlist_comp = visit(tlc);
            return new AtomNode(null, testlist_comp);
        } else {
            return new AtomNode(null, null);
        }
    }

in

        } else if (ctx.OPEN_BRACE() != null && ctx.CLOSE_BRACE() != null
            || ctx.OPEN_BRACK() != null && ctx.CLOSE_BRACK() != null 
			| |ctx.OPEN_PAREN() != null && ctx.CLOSE_PAREN() != null) {
            if (tlc != null) {
            	Node testlist_comp = visit(tlc);
            	return new AtomNode(null, testlist_comp);
        	} else {
            	return new AtomNode(null, null);
        	}
        }
        return new AtomNode(null, null);
    }

Guardando con @L0P0P abbiamo notato che per i blocchi diversi dalle funzioni non ha senso aumentarne l'offset.
Ad esempio,

x = 10
if x == 10:
	x = 3

print(x) # 3

invece ha senso per roba del tipo

x = 10
def foo():
	if x == 10:
		x = 3
	print(x) # 3

foo()
print(x) # 10

Guardando le slide del prof abbiamo riscontrato dei dubbi su due codici

1. Viene detto che l'assegnamento deve essere fatto in due righe diverse, ma questo è valido (a, b = b, a).

a = 3
b = 1

print(a, b) # 3, 1
a, b = b, a
print(a, b) # 1, 3

2. In questo caso la x non è usata ma, stando alle slide, dovremmo spostarla fuori dal ciclo while (inutilmente) e non eliminarla (come ci dice qualsiasi altro testo). Inoltre qui dovremmo obbligatoriamente anche togliere il ciclo while e risparmiare i 10 cicli.

while n < 10:
  x = a, b # (3, 1)

Da titolo, la e nel range dovrebbe essere un iteratore, non una espressione. Una roba del tipo for i range(n < 10) non è valida in Python.

Il punto è che un iteratore è una classe con dentro i metodi __iter__ e __next__. Come stra diamine dovremmo intendere sta roba? Nelle slide c'è scritto che e deve essere un'espressione.

Utilizzare .getChild() al posto di singole visite su simple_stmts e compound_stmts. In questo modo abbiamo sequenzialmente l'ordine di quello che viene parsato.

Risolve il problema di avere un albero con, ad esempio,

• simple
• compound
• simple