Errata corrige 1.0.0 - Fixing more typos

README.md

@@ -11,7 +11,7 @@
   - [La squadra](#la-squadra)
 
 ## Il progetto
-Questo testo è una dispensa di appunti scritta da studenti; lo scopo è quello di raccogliere i contenuti del corso di Linugaggi Formali e Compilatori e organizzarli secondo un'esposizione quanto più completa, efficace ed intuitiva possibile, tanto per lo studente desideroso di ottenere un'ottima padronanza degli argomenti, quanto anche per lo studente pigro in cerca di risorse per "portare a casa" l'esame.
+Questo testo è una dispensa di appunti scritta da studenti; lo scopo è quello di raccogliere i contenuti del corso di Linguaggi Formali e Compilatori e organizzarli secondo un'esposizione quanto più completa, efficace ed intuitiva possibile, tanto per lo studente desideroso di ottenere un'ottima padronanza degli argomenti, quanto anche per lo studente pigro in cerca di risorse per "portare a casa" l'esame.
 
 Gli appunti sono stati presi durante il corso di Linguaggi Formali e Compilatori tenuto dalla professoressa Paola Quaglia per il Corso di Laurea in Informatica, DISI, Università degli studi di Trento, anno accademico 2020-2021. I contenuti provengono quindi primariamente dalle lezioni della professoressa, mentre invece ordine ed esposizione sono in gran parte originali. Allo stesso modo, la maggior parte degli assets (figure, grafi, tabelle, pseudocodici) sono contenutisticamente tratti dal materiale della professoressa, ma ricreati e molto spesso manipolati dagli autori; inoltre, per ottenere il risultato appena citato, è stato molto spesso necessario abbandonare quasi del tutto l'esposizione della professoressa e usarla, appunto, come canovaccio per svilupparne una originale.
 

src/chapters/01/chapter01.tex

@@ -13,20 +13,20 @@ \chapter{Introduzione}
 \section{Il compilatore}
 \subsection{Cos'è un compilatore}
 Il compilatore, generalizzando, è un meccanismo che trasforma il codice sorgente in codice eseguibile.
-Una caratteristica del codice eseguibile è l'essere machine dependent, difatti noi studieremo i principi generali di questa traduzione ma dobbiamo tenere bene a mente il fatto che ogni tipo di macchina ha il suo proprio linguaggio macchina che deve essere utilizzato per scrivere gli eseguibili da essa utilizzabili. Durante il corso, useremo spesso come punto di riferimento il compilatore gcc: tale progetto è in sviluppo da 20 anni e consta di ben più di due milioni di righe di codice!
+Una caratteristica del codice eseguibile è l'essere machine dependent, difatti noi studieremo i principi generali di questa traduzione ma dobbiamo tenere bene a mente il fatto che ogni tipo di macchina ha il suo proprio linguaggio macchina che deve essere utilizzato per scrivere gli eseguibili da essa utilizzabili. Durante il corso, useremo spesso come punto di riferimento il compilatore gcc: tale progetto è in sviluppo da 20 anni e conta ben più di due milioni di righe di codice!
 
 \paragraph{A cosa serve}
-L’esempio classico di utilizzo di un compilatore è la traduzione da codice \texttt{c} in assembly.
+L'esempio classico di utilizzo di un compilatore è la traduzione da codice \texttt{c} in assembly.
 Un codice in assembly, tuttavia non è ancora eseguibile. Manca il passaggio di conversione da assembly a codice binario; tuttavia, questo passaggio non è così complesso dato che assembly ha una corrispondenza quasi 1:1 con il binario.
-Ma quest’ultima traduzione non è l’unico passaggio mancante: rimane ancora da affrontare la fase di linking.
+Ma quest'ultima traduzione non è l'unico passaggio mancante: rimane ancora da affrontare la fase di linking.
 
 \subsection{Le fasi del processo di compilazione}
 In questa sezione presentiamo le fasi del processo di compilazione come se fossero in pipeline, ma sappi che per ragioni di efficienza vengono spesso sovrapposte. Due punti fondamentali di questo processo sono i seguenti:
 \begin{itemize}
     \item se scriviamo il programma in un certo linguaggio, lo dovremo compilare con il compilatore dedicato esattamente a quel linguaggio;
     \item quando scrivo codice per un certo compilatore devo rispettare la grammatica del linguaggio per cui il compilatore lavora.
 \end{itemize}
-La grammatica di un linguaggio definisce la struttura legale delle varie operazioni possibili in quel linguaggio; ad esempio, può definire questa forma per un’operazione di assegnamento:
+La grammatica di un linguaggio definisce la struttura legale delle varie operazioni possibili in quel linguaggio; ad esempio, può definire questa forma per un'operazione di assegnamento:
 \begin{equation*}
 	\textrm{\texttt{Identifier Assign Expression Semicolon}}
 \end{equation*}
@@ -36,29 +36,29 @@ \subsection{Le fasi del processo di compilazione}
 Avendo chiarito il punto di partenza, possiamo procedere con una descrizione delle fasi della compilazione.
 
 \subsubsection{Analisi lessicale}
-Il primo passaggio che compie il compilatore è l’analisi lessicale: questa traduce un flusso di caratteri in un flusso di \emph{tokens}, vale a dire che risolve ogni statement, riconoscendo il ruolo degli elementi che lo compongono e ritornandone una nuova stringa processata. Per esempio, traduce questa linea:
+Il primo passaggio che compie il compilatore è l'analisi lessicale: questa traduce un flusso di caratteri in un flusso di \emph{tokens}, vale a dire che risolve ogni statement, riconoscendo il ruolo degli elementi che lo compongono e ritornandone una nuova stringa processata. Per esempio, traduce questa linea:
 \begin{equation*}
 	\textrm{\texttt{pippo = 2*3;}}
 \end{equation*}
 In una nuova linea che descrive la funzione dei vari elementi, qualcosa di simile a:
 \begin{equation*}
 	\textrm{\texttt{<ID, pippo> ASS <NUM,2 > MUL <NUM,3> SEMCOL}}
 \end{equation*}
-In questa fase è sufficiente dire che i token che otteniamo contengono le informazioni sul tipo di dato o comando che ogni singola stringa identifica. Nota che non vengono perse informazioni, non si tratta di una traduzione in cui la stringa dell’ID viene eliminata: si tiene la stringa \texttt{pippo} e vi si assegna il ruolo di identificatore (ID).
+In questa fase è sufficiente dire che i token che otteniamo contengono le informazioni sul tipo di dato o comando che ogni singola stringa identifica. Nota che non vengono perse informazioni, non si tratta di una traduzione in cui la stringa dell'ID viene eliminata: si tiene la stringa \texttt{pippo} e vi si assegna il ruolo di identificatore (ID).
 
 \subsubsection{Analisi sintattica}
-Dopo l’analisi lessicale arriva l’analisi sintattica: questa analisi verifica che la sequenza di token sia aderente alla grammatica del linguaggio che stiamo utilizzando, ed è la fase in cui compaiono i temuti syntax error.
+Dopo l'analisi lessicale arriva l'analisi sintattica: questa analisi verifica che la sequenza di token sia aderente alla grammatica del linguaggio che stiamo utilizzando, ed è la fase in cui compaiono i temuti syntax error.
 
 Se rispettiamo le regole della grammatica il flusso di token viene tradotto in un parse tree (o meglio ancora, dipendentemente dal compilatore, in un albero di sintassi astratta). Ecco il parse tree che si può ricavare dal nostro esempio:
 \begin{figure}[H]
 	\centering
 	\subimport{assets/figures/}{parse-tree.tex}
 	\caption{Esempio di parse tree}
 \end{figure}
-La struttura del parse tree è derivata dalla grammatica del linguaggio. Ad esempio, \texttt{<NUM,2> MUL <NUM,3>} sono sottoalberi di \texttt{ASS} poiché la grammatica del linguaggio prevede che l’assegnazione abbia questa forma. 
+La struttura del parse tree è derivata dalla grammatica del linguaggio. Ad esempio, \texttt{<NUM,2> MUL <NUM,3>} sono sottoalberi di \texttt{ASS} poiché la grammatica del linguaggio prevede che l'assegnazione abbia questa forma. 
 
 \paragraph{}
-Più la struttura del parse tree è minimale più le fasi successive sono efficienti; qui che entra in gioco l’AST, che semplifica ancora lo schema: l’albero di sintassi astratta (abstract syntax tree, AST) è ottenuto dal parse tree compattando delle parti che non saranno utili nelle fasi seguenti della compilazione.
+Più la struttura del parse tree è minimale più le fasi successive sono efficienti; qui che entra in gioco l'AST, che semplifica ancora lo schema: l'albero di sintassi astratta (abstract syntax tree, AST) è ottenuto dal parse tree compattando delle parti che non saranno utili nelle fasi seguenti della compilazione.
 \begin{figure}[H]
 	\centering
 	\subimport{assets/figures/}{abstract-syntax-tree.tex}
@@ -69,25 +69,25 @@ \subsubsection{Analisi sintattica}
 \paragraph*{}
 Non è facile scrivere una grammatica che possa essere analizzata con efficienza da un compilatore e che, al tempo stesso, generi parse tree più semplici possibili; ma di questo discuteremo in futuro. È da notare che esistono svariate forme di compilatori, noi ne stiamo vedendo una presentazione generale, ma, in molti casi, fasi come creazione di parse tree e AST vengono spesso parallelizzate.
 \paragraph{}
-L’output dell’analisi sintattica è chiamato \emph{tree}, ma non necessariamente è un albero: spesso può essere un grafo. Ad esempio in un’operazione del tipo:
+L'output dell'analisi sintattica è chiamato \emph{tree}, ma non necessariamente è un albero: spesso può essere un grafo. Ad esempio in un'operazione del tipo:
 \texttt{pippo = pippo * 2}
-il nodo pippo sarebbe collegato sia alla radice che all’operatore \texttt{ASS}, creando quindi un grafo.
+il nodo pippo sarebbe collegato sia alla radice che all'operatore \texttt{ASS}, creando quindi un grafo.
 \begin{figure}[H]
 	\centering
 	\subimport{assets/figures/}{pippo-tree.tex}
 	\caption{Abstract syntax tree che diventa un grafo quando la variabile a cui si assegna il valore fa parte dell'espressione alla destra dell'assegnamento.}
 \end{figure}
 
 \subsubsection{Analisi semantica}
-Ora è la fase dell’analisi semantica. Un esempio di operazione di analisi semantica è quello di capire se stiamo utilizzando il giusto operatore di moltiplicazione per l’operazione che vogliamo effettuare. Stiamo chiaramente riferendoci a quei linguaggi in cui esistono diversi significati per uno stesso operatore, come nel caso in cui l'operatore \texttt{MUL} può significare moltiplicazione sia tra interi sia tra float. Quindi si può dire che in questo caso l’analisi semantica chiarisce quale significato ha l’operatore \texttt{MUL}: nell’esempio riportato in \ref{esempioAST} \texttt{MUL} = moltiplicazione tra due variabili di tipo \texttt{NUM}.
+Ora è la fase dell'analisi semantica. Un esempio di operazione di analisi semantica è quello di capire se stiamo utilizzando il giusto operatore di moltiplicazione per l'operazione che vogliamo effettuare. Stiamo chiaramente riferendoci a quei linguaggi in cui esistono diversi significati per uno stesso operatore, come nel caso in cui l'operatore \texttt{MUL} può significare moltiplicazione sia tra interi sia tra float. Quindi si può dire che in questo caso l'analisi semantica chiarisce quale significato ha l'operatore \texttt{MUL}: nell'esempio riportato in \ref{esempioAST} \texttt{MUL} = moltiplicazione tra due variabili di tipo \texttt{NUM}.
 \begin{figure}[H]
 	\centering
 	\subimport{assets/figures/}{semantica-mul.tex}
 	\caption{La semantica di \texttt{MUL} deve essere specificata}
 \end{figure}
 
 \subsubsection{Generazione del codice intermedio}
-È il momento della generazione del codice intermedio: in questa fase viene generato un codice testuale traducendo il parse tree. Queste istruzioni sono leggibili dall’uomo ma non è né assembly né codice effettivo, d’altronde si chiama intermedio, no? Nell'esempio in \ref{codice_intermedio} abbiamo sulla sinistra il parse tree e sulla destra abbiamo un esempio del codice intermedio generato.
+È il momento della generazione del codice intermedio: in questa fase viene generato un codice testuale traducendo il parse tree. Queste istruzioni sono leggibili dall'uomo ma non è né assembly né codice effettivo, d'altronde si chiama intermedio, no? Nell'esempio in \ref{codice_intermedio} abbiamo sulla sinistra il parse tree e sulla destra abbiamo un esempio del codice intermedio generato.
 \begin{figure}[H]
     \begin{minipage}{.5\textwidth}
 		\raggedleft
@@ -107,7 +107,7 @@ \subsubsection{Generazione del codice intermedio}
 \end{figure}
 
 \subsubsection{Generazione del target code}
-Questa fase consiste nella traduzione del codice intermedio nell’assembly della specifica macchina. Il codice binario non è necessariamente il target code della compilazione: ad esempio, potremmo essere su una VM e quindi generare una sorta di bytecode, o magari potremmo avere come obiettivo quello di tradurre in \texttt{c} per poi usare il gcc che sappiamo essere super-efficiente.
+Questa fase consiste nella traduzione del codice intermedio nell'assembly della specifica macchina. Il codice binario non è necessariamente il target code della compilazione: ad esempio, potremmo essere su una VM e quindi generare una sorta di bytecode, o magari potremmo avere come obiettivo quello di tradurre in \texttt{c} per poi usare il gcc che sappiamo essere super-efficiente.
 
 \section{Riassumendo le fasi della compilazione}
 Riassumendo i passaggi necessari per la compilazione sono:
@@ -120,7 +120,7 @@ \section{Riassumendo le fasi della compilazione}
 \end{enumerate}
 Possiamo dividere questi passaggi in due gruppi:
 \begin{itemize}[]
-    \item \emph{Front-end}: dall’analisi lessicale fino al codice intermedio.
+    \item \emph{Front-end}: dall'analisi lessicale fino al codice intermedio.
     \item \emph{Back-end}: tutto il resto.
 \end{itemize}
 Ma perché passiamo dalla fase del codice intermedio? Per ragioni di modularità:

src/chapters/02/assets/figures/dangling_else_1.tex

@@ -1,29 +1,32 @@
-\documentclass[varwidth]{standalone}
-\usepackage[T1]{fontenc}
+\documentclass[convert = false, tikz]{standalone}
 \usepackage[utf8]{inputenc}
-\usepackage[english, italian]{babel}
+\usepackage{tikz}
+\usetikzlibrary{automata, positioning, arrows, shapes.geometric, decorations.pathmorphing}
 
-\usepackage{forest}
-\usepackage{../../../../style_tree}
+\usepackage{../../../../style_automata}
 
 % arara: pdflatex
 % arara: latexmk: { clean: partial }
 \begin{document}
-    \begin{forest}
-        % derivation tree
-        [S
-            [if]
-            [b]
-            [then]
-            [S
-                [if]
-                [b]
-                [then]
-                [other]
-                [else]
-                [other]
-            ]
-        ]
-    \end{forest}
-\end{document}
+    \tikzset{
+    node distance=2cm, % specifies the minimum distance between two nodes.
+    }
+    \begin{tikzpicture}
 
+    % Apex angle 60 degrees
+    \node[](S1){\textbf{S}};
+
+    \draw[] ([yshift=-1cm, xshift=1cm]S1.south) node[] (S2) {\textbf{S}};
+
+    \draw[] (S2.south) node[isosceles triangle, rotate=90, isosceles triangle apex angle=110, draw, minimum size=1.5cm, anchor=apex, fill=violet!20] (T) {};
+
+    \draw[] ([yshift=-3cm, xshift=0.15cm]S1.south) node[] (text) {\textbf{if b then if b then other else other}};
+
+    \draw [] (S1.south) -- (S2.north);
+    \draw [] (S1.south) -- ([xshift=-1.9cm]text.north);
+    \draw [] (S1.south) -- ([xshift=-2.5cm]text.north);
+    \draw [] (S1.south) -- ([xshift=-2.9cm]text.north);
+
+
+    \end{tikzpicture}
+\end{document}

src/chapters/02/assets/figures/dangling_else_2.tex

@@ -1,29 +1,34 @@
-\documentclass[varwidth]{standalone}
-\usepackage[T1]{fontenc}
+\documentclass[convert = false, tikz]{standalone}
 \usepackage[utf8]{inputenc}
-\usepackage[english, italian]{babel}
+\usepackage{tikz}
+\usetikzlibrary{automata, positioning, arrows, shapes.geometric, decorations.pathmorphing}
 
-\usepackage{forest}
-\usepackage{../../../../style_tree}
+\usepackage{../../../../style_automata}
 
 % arara: pdflatex
 % arara: latexmk: { clean: partial }
 \begin{document}
-    \begin{forest}
-        % derivation tree
-        [S
-            [if]
-            [b]
-            [then]
-            [S
-                [if]
-                [b]
-                [then]
-                [other]
-            ]
-            [else]
-            [other]
-        ]
-    \end{forest}
-\end{document}
+    \tikzset{
+    node distance=2cm, % specifies the minimum distance between two nodes.
+    }
+    \begin{tikzpicture}
 
+    % Apex angle 60 degrees
+    \node[](S1){\textbf{S}};
+
+    \draw[] ([yshift=-1cm]S1.south) node[] (S2) {\textbf{S}};
+
+    \draw[] (S2.south) node[isosceles triangle, rotate=90, isosceles triangle apex angle=80, draw, minimum size=1.5cm, anchor=apex, fill=violet!20] (T) {};
+
+    \draw[] ([yshift=-3cm, xshift=0.1cm]S1.south) node[] (text) {\textbf{if b then if b then other else other}};
+
+    \draw [] (S1.south) -- (S2.north);
+    \draw [] (S1.south) -- ([xshift=1.65cm]text.north);
+    \draw [] (S1.south) -- ([xshift=2.55cm]text.north);
+    \draw [] (S1.south) -- ([xshift=-1.9cm]text.north);
+    \draw [] (S1.south) -- ([xshift=-2.5cm]text.north);
+    \draw [] (S1.south) -- ([xshift=-2.9cm]text.north);
+
+
+    \end{tikzpicture}
+\end{document}