Progetto Parte II

1
Progetto Parte II

• OCAML

2
Obiettivo

• Interprete del linguaggio didattico (PICO) in ML
• Riprogettare linterprete utilizzando le
  caratteristiche di OCAML
• In particolare, usare i tipi di dato astratto
• Moduli ed Interfacce

3
Limiti dellInterprete

• Funziona
• Il programma e molto a basso livello
• Non e organizzato in moduli, ogni parte dipende
  dallimplementazione delle altre
• Di conseguenza, risulta difficile capire il
  codice
• Difficilmente estendibile, modificabile (se per
  esempio si dovesse aggiungere istruzioni nel
  linguaggio imperativo considerato)

4
Le strutture run-time

• Le componenti dello stato, env e store sono
  realizzate a basso livello
• Sono definite da semplici tipi, insiemi di valori
• Mancano le relative operazioni
• Di conseguenza, non e possibile garantire
  proprieta invarianti delle strutture a tempo di
  esecuzione
• Segnalando eventualmente errori

5
Funzioni di valutazione semantica

• Per le varie componenti
• valProg prog sigma mu-gt sigma mu
• valCom com sigma mu-gt sigma mu
• valDecl com sigma mu-gt sigma mu
• valExp aExp sigma mu-gt value sigma mu
• La loro implementazione dipende
  dallimplementazione dellenv (sigma) e dello
  store (mu)

6
Frame

• Definizione Matematica (astratta) il frame e
  una funzione
• frame Ide ---gt Den
• Implementazione
• type fi Frame of
• (string denotation) list
• Definizione molto a basso livello, una lista di
  coppie (identificatore, valore)

7
Svantaggi

• Limplementazione e molto distante dalla
• definizione astratta
• Limplementazione del Frame (la lista di coppie)
  non ha proprieta invarianti
• Le funzioni dellinterprete che lavorano sul
  frame lavorano direttamente sulla lista di coppie
  (non ce astrazione sui dati)

8
Esempio proprieta

• Una lista di coppie (identificatore, valore
  denotabile) non necessariamente rappresenta una
  funzione
• (x,l1),(y,l2),(x,l3)
• Quale il valore della variabile x? Questo non
  e un Frame!
• Bisognerebbe garantire questa proprieta per
  costruzione

9
Le Operazioni

• Non e possibile dato che le operazioni sono
  scollegate dal tipo di dato
• Addirittura alcune operazioni, che si usano nella
  definizione astratta della semantica tramite SOS,
  non sono neanche direttamente implementate in
  modo esplicito
• Per esempio loperazione di modifica di un frame.

10
Modifica di un frame

• phi d/x (y) phi (y) se x e diverso da y
• d se xy
• La definizione cosi data risulta corretta
• anche nelleventualita che un legame diverso
• da Unbound per x esista gia
• non e molto corretto solo per programmi
  sintatticamente corretti

11
Ambiente env

• Definizione Astratta envStack(Frames)
• Implementazione
• type sigma Stack of fi list
• Definizione molto a basso livello, una lista di
  frames
• Le funzioni che devono operare sullenv operano
  direttamente sulla lista
• Le operazioni di pop(),push(), top() non vengono
  fornite
• Anche in questo caso non e chiaro quali devono
  essere le proprieta invarianti della lista di
  frames

12
Modifica dellenv

• let rec addBind sigma (x,y)
• match sigma with
• Stack Frame -gt
• Stack Frame(x,y)
  
• Stack ((Frame f)fs) -gt
• Stack ((Frame (append f (x,y))) fs)
• Loperazione e implementata in modo ricorsivo
  sulla lista che implementa la pila
• mancano anche alcuni casi come quello della pila
  vuota, al solito non e garantito dalla
  definizione della pila che non possa essere vuota
• Limplementazione dipende dallimplementazione
  del Frame (non ce astrazione)

13
Esempio valCom

• let valCom c (sigma,mu) match c with
• Block l -gt
• let (Stack (frl),mu1)
  valStmtL l
• ((match sigma with Stack fl -gt
  Stack (Framefl)) ,mu)
  in (Stack rl, mu1)
• valuta l nello stato in cui un frame vuoto
  Frame
• e stato messo al top della pila
• restituisce lenv da cui e stato fatto pop (le
  variabili del blocco sono locali)
• codice parecchio complicato, lontano dalla
  definizione della regola della semantica

14
Esempio valExp

• Problemi analoghi anche in altre regole
  semantiche, che richiedono operazioni di push e
  pop dalla pila, tipo la chiamata di funzione
• Stack sl -gt
• addBind (addBind (Stack
• (Frame sl)) (f,l)) ("retVal",l1))

15
Memoria

• Definizione Astratta
• mu Loc ---gt Val
• IMPLEMENTAZIONE
• type 'a mu Mem of 'a list
• Definizione molto a basso livello, una lista
  polimorfa
• Si usera per memorizzare coppie (identificatore,
  valore)

16
Problemi

• Problemi sono simili a quelli del Frame
• Quali sono le proprieta di questa lista?
• E una funzione?
• Nel caso della memoria pero e ancora piu
  complesso, non solo deve essere una funzione, ma
  esiste il problema dellallocazione della memoria

17
Per esempio

• free Store---gt Loc Store
• restitituisce una nuova locazione libera e la
  memoria modificata di conseguenza (alla nuova
  locazione viene assegnato il valore omega)
• Deve esserci una politica per gestire le
  locazioni

18
Come abbiamo visto

• La lista viene usata in questo modo
• (l0,v1),(l2,v2),(l3,v3)
• Loperazione di free restituisce l4 e la memoria
• (l0,v1),(l2,v2),(l3,v3),(l4,omega)
• Esiste un uso inteso della lista di coppie che
  implementa la memoria, ma non e garantito per
  costruzione

19
Progetto

• Usare i tipi di dato astratto di OCAML per
  migliorare la struttura del programma
• Parte I definire moduli che realizzino le
  strutture a tempo di esecuzione (lo stato),
  frame, memoria, env
• Parte II riprogrammare le funzioni di
  valutazione semantica usando i nuovi tipi di dato
  astratti

20
Moduli ed Interfacce

• per supportare in modo semplice i concetti di
  encapsulation e data hiding
• linterfaccia e definita da una module
  signature
• limplementazione (o le) e definita da una
  module structure

21
Signature interfaccia

• dichiara il tipo
• dichiara le operazioni tramite metodi pubblici,
  (nome, parametri, tipo)

22
Structure implementazione

• implementa il tipo ed i metodi associati
• puo contenere definizioni ausiliarie, da fuori
  e visibile solo quello che e specificato nella
  corrispondente interfaccia (signature)
• Limplementazione puo (deve) garantire
  proprieta invarianti del tipo di dato

23
Frame, Memoria, Env

• Per ciascuna componente dare una relativa
  interfaccia
• Quali operazioni?
• Operazioni per inizializzare la struttura dati
• Operazioni per modificarla (quelle che servonoin
  base alluso nellinterprete) nello stile degli
  esempi che abbiamo visto a lezione
• Non Modificabile (consiglio)

24
Attenzione

• I tipi di dato astratti hanno delle proprieta
• Le operazioni le devono garantire
• Come abbiamo visto e sempre consigliabile usare
  le eccezioni per trattare i casi non previsti

25
Frame

• Vogliamo che sia una funzione
• Operazione per creare un frame vuoto (ovunque
  indefinto)
• Operazioni per inserire un nuovo legame, per
  cercare il valore associato ad un identificatore
  (altro?)
• Eccezioni per casi non previsti per esempio,
  inserisco un identificatore che e gia dichiarato

26
Memoria

• Vogliamo che sia una funzione, e che le locazioni
  siano assegnate in modo incrementale
• Operazione per creare un memoria vuota (ovunque
  indefinita)
• Operazioni per inserire un nuovo legame, per
  cercare il valore associato ad un locazione, per
  modificare il valore memorizzato in una
  locazione, per scegliere una nuova locazione
  (altro?)
• Eccezioni per casi non previsti ce ne sono un tot

27
Env

• Vogliamo che sia una Pila di Frames
• Operazione per creare una pila vuota
• Operazioni di pop, push, top
• Eccezioni per casi non previsti esempio, faccio
  pop su una pila che e vuota

28
Implementazione

• Per ciascuna componente dare una implementazione
  dellinterfaccia
• Si puo anche usare limplementazione vista
  nellinterprete Pico
• Frame puo essere realizzato una lista di coppie
  (identificatore, valore)
• Env puo essere realizzato una lista
• Store puo essere realizzato una lista di coppie
  (locazione, valore)
• Liste adatte per TDA non modificabili

29
Parte II Cosa Cambia?

• Limplementazione dello stato e invisibile al
  codice dellinterprete
• Alle funzioni di valutazione semantica
• valProg prog sigma mu-gt sigma mu
• valCom com sigma mu-gt sigma mu
• valDecl com sigma mu-gt sigma mu
• valExp aExp sigma mu-gt value sigma mu

30
Esempio valCom

• let valCom c (sigma,mu) match c with
• Block l -gt
• let (Stack (frl),mu1)
  valStmtL l
• ((match sigma with Stack fl -gt
  Stack (Framefl)) ,mu) in (Stack
  rl, mu1)
• La semantica del blocco va modificata, il codice
  non vede limplementazione dellenv e del frame
  tramite lista tramite lista
• Le strutture dello stato andranno manipolate solo
  tramite le operazioni pubbliche fornite dalla
  relativa interfaccia

31
Vantaggio

• Non solo linterprete diventa piu astratto, non
  dipendente dallimplementazione delle strutture
  dati
• Il codice delle funzioni di valutazione semantica
  risultera piu semplice, piu vicino alla
  semantica data in forma SOS

32
Informazioni Pratiche

• Lo svolgimento dei due progetti puo rimpiazzare
  lesame scritto
• Il progetto si puo fare in gruppi di al massimo
  due persone (va consegnato insieme, indicando i
  nomi)
• Lesame orale puo essere sostenuto
  indipendentemente (in date da concordare, non
  sono fissate)

33
Documentazione

• Per facilitare la correzione mandare insieme ai
  files con il codice, una breve relazione
• La relazione dovrebbe spiegare brevemente le
  principali scelte adottate nel programma

34
Quando vanno consegnati?

• Entro linizio delle lezioni del secondo semestre
• Per qualsiasi informazione, problemi e/o per
  fissare un ricevimento a Spezia
• levifran_at_di.unipi.it