Definizione dei requisiti

Volendo riassumere quanto emerso dalla fase di analisi, è quindi possibile definire, come quadro generale circa i requisiti richiesti per il primo prototipo, quanto segue. Il transpiler Snap2ino deve essere in grado di prendere come sorgente, in input, il file xml rappresentante il progetto Snap! "Micromondo della Matrice", validato e corretto. Questo deve poi essere filtrato in modo da mantenere solo le informazioni di interesse da convertire, ossia la sezione rappresentante lo script definito e quella delle relative variabili locali. Infine, deve convertire tali informazioni generando, secondo la sintassi del linguaggio C/C++, lo sketch Wiring, rappresentato dal solo file .ino, contenente la definizione delle variabili globali rappresentanti quelle locali definite in Snap!, e il comportamento dello script collocato all’interno della procedura loop(), facendo in modo che sia eseguito una sola volta.

4.3

Progettazione

Descritti l’input da processare e l’output da generare, è ora necessario stabilire come passare dal primo all’ultimo, ossia convertire le informazioni (il codice) definite attraverso la sintassi xml, in uno sketch Wiring equivalente e compilabile per la piattaforma Arduino.

Partendo dall’analisi precedentemente effettuata, i requisiti emersi da questa possono essere identificati nei seguenti punti, caratterizzanti il fun- zionamento del transpiler da realizzare:

1. Acquisizione del sorgente da processare e filtraggio delle informazioni (tag) significative in esso contenute (4.3.2).

4.3. PROGETTAZIONE 71

3. Conversione delle informazioni filtrate e generazione dei file richiesti, costituenti lo sketch da compilare e caricare su Arduino (4.3.4). Di queste tre punti, il vero cuore della fase di progettazione del transpi- ler da realizzare risiede però negli ultimi due, ossia nel riuscire a leggere e capire le informazioni filtrate, e a convertire queste in maniera equivalente nel linguaggio di destinazione. Per poter fare ciò, si è ricorso alla definizione di un DLS (Domain-Specific Language) rappresentante il linguaggio compo- sto dalle informazioni filtrate, e chiamato come il transpiler da realizzare: Snap2ino.

Domain-Specific Languages Col termine DSL di intende un qualsiasi linguaggio di programmazione, o di specifica, appositamente realizzato per l’utilizzo all’interno di uno specifico dominio applicativo. A differenza dei linguaggi di programmazione general purpose (come il C o Java), non sono realizzati con lo scopo di poter risolvere un qualsiasi genere di problema, ma una ben precisa classe e tipologia in maniera più semplice e veloce rispetto ai primi. Alcuni esempi sono SQL, Mathematica, HTML e molti altri. Una vol- ta realizzato un programma, o specifica, in un particolare DSL, questo può poi essere interpretato o compilato, a seconda delle esigenze, secondo uno specifico linguaggio general purpose, piuttosto che essere manipolato e pro- cessato, nel caso rappresenti semplicemente una particolare organizzazione di dati, da particolari sistemi specifici [38, p. 7].

Detto questo, implementare un DSL significa sviluppare un programma che sia in grado di leggere un sorgente scritto in quel particolare linguaggio domain-specific, farne il parsing, processarlo e, possibilmente, interpretarlo o convertirlo in un altro linguaggio [38, p. 9].

Grammatica e Parsing Il punto di partenza nell’implementazione di un qualunque DSL è la definizione della grammatica, ossia l’insieme di regole attraverso le quali definire la sintassi del linguaggio. Solo attraverso la de- finizione della grammatica del proprio linguaggio è infatti possibile leggere un programma scritto in tale linguaggio, nonché verificarne la correttezza. In particolare, prima di poter leggere il programma, occorre innanzitutto verificare che sia effettivamente codificato nel linguaggio che ci aspettiamo, ossia che ne rispetti la sintassi.

Per fare questo occorre, in prima battuta, scomporre il sorgente dato in tanti piccoli token, ossia elementi atomici del linguaggio, come: parole chiave (p.e. classin Java), identificatori (come il nome della classe) o nomi

logici, parentesi, etc) e valori letterali (p.e costanti numeriche, stringhe, etc). Il processo che consente di convertire generiche sequenze di caratteri in una sequenza di token è detta analisi lessicale (lexical analysis) ed è eseguita ad opera di un analizzatore lessicale (a.k.a lexer ) attraverso opportune Regular Expressions2.

Una volta ottenuta la sequenza di token dal file sorgente, è quindi possi- bile verificare se questi rispettano la struttura sintattica definita dalla gram- matica del nostro linguaggio, nel processo chiamato parsing [38, pp. 10, 11].

Abstract Syntax Tree, Validator e Code Generator Oltre all’analisi sintattica, un’altra fondamentale attività svolta durante il parsing è la gene- razione del cosiddetto Abstract Syntax Tree, ossia una particolare struttura dati ad albero, utilizzata per la rappresentazione in memoria del program- ma parsato, nella quale ogni nodo rappresenta un costrutto utilizzato del linguaggio.

Il motivo principale alla base della generazione e l’utilizzo di tale strut- tura dati risiede nel fatto che l’analisi sintattica di un programma non è sufficiente a garantirne la piena correttezza, in particolare la correttezza se- mantica. Infatti, solo potendo accedere a una rappresentazione in memoria del programma è possibile effettuare importanti verifiche semantiche come: il type checking, ossia la verifica del corretto utilizzo dei tipi di dato (negli assegnamenti, nelle operazioni, etc), e lo scope checking, ossia il controllo sulla visibilità e gli accessi (di/a variabili, campi, metodi, etc), per il quale è, in genere, richiesto il supporto di un’apposita tabella dei simboli3.

Una volta verificata la correttezza semantica del programma, ad opera del cosiddetto validator e attraverso l’ispezione dei nodi dell’AST, è poi possibile eseguire l’ultima importante fase operativa: l’interpretazione/generazione del codice [38, p. 12]. Questa, eseguita ad opera di un componente chiamato code generator e attraverso l’ispezione della rappresentazione in memoria del programma parsato e validato (AST), consiste nella generazione dei sorgenti richiesti, con riferimento all’organizzazione del codice richiesta per questi, attraverso il mapping dei costrutti definiti nel programma parsato, contenuti nell’AST, nelle controparti equivalenti per il linguaggio di destinazione.

2

Regular Expressions: letteralmente Espressioni Regolari, sono sequenze di simboli (caratteri) utilizzate per l’identificazione di sottostringhe, stringhe o insieme di stringhe.

3

tabella dei simboli: struttura dati contenente le informazioni su tutti gli elementi simbolici incontrati durante l’analisi del sorgente, come: nome, visibilità (scope), eventuale tipo, etc.

4.3. PROGETTAZIONE 73