Changes between Version 21 and Version 22 of Variante2

Timestamp:

Sep 29, 2006, 10:33:55 AM (18 years ago)

Author:

soujak

Comment:

Interpreter visitor: commenti sulle definizioni e sulle gerarchie di ambienti

Variante2

@@ -85 +85 @@
 nostri ''visitor'': `Interpreter` e `PrettyPrinter`.
 
+20060926-1355 [[BR]]
+L'eterogeneita' dell'albero rispetto al modello (inteso come espressioni) pone
+problemi rilevanti, apparentemente non risolvibili se non a spese dell'eleganza
+progettuale finora perseguita.
+La soluzione scelta e' la creazione di un supertipo di ogni entita' del modello,
+il che si traduce nella creazione dell'interfaccia `SchemeEntity`. Si e' inoltre
+pensato di aggiungere anche una classe astratta `SchemeEntityAbstract` che
+permette un'implementazione di default.
+
+
 === API di manipolazione generica ===
 
@@ -118 +128 @@
 una lista che li contiene?
  
+20060927-1813 [[BR]]
+Le API di manipolazione del modello (''getters'' e ''setters'') soffrono della
+stessa incoerenza di Java riguardo ai tipi: i valori di tipo
+`Scheme[Expression | Value][Int | Bool]` mantengono campi interni sotto forma di
+tipi primitivi mentre il resto del modello sfrutta oggetti. Tale eterogeneita'
+si manifesta in una strategia di passaggio/ritorno dei parametri che e',
+rispettivamente, per valore e per riferimento.
+
+
 
 === API di manipolazione specifica ===
@@ -213 +232 @@
 Rimane insoluta una questione: come innescare la valutazione, ora che il metodo
 `applyTo()` e' da considerarsi deprecato? Qualora si abbia il tempo di rendere
-utilizzabile l'intero sistema sara' necesario elaborare una soluzione.
+utilizzabile l'intero sistema sara' necessario elaborare una soluzione.
+
+20060927 [[BR]]
+Invece di mantenere traccia dei vari ambienti locali (in caso di gerarchie di
+ambienti locali) sfruttando l'annidamento delle chiamate di `visit()`, si
+potrebbe guadagnare in eleganza utilizzando una cara e vecchia ... pila.
+20060928-1736 [[BR]]
+La profondita' della gerarchia degli ambienti e' troppo bassa da giustificare un
+aumento della complessita' del codice.
+
+20060928-1910 [[BR]]
+L'`interpreter` portebbe essere arricchito con un metodo che, preso in input un
+programma (inteso come lista di definizioni), faccia partire la valutazione.
+Il che significa iterare su tale lista arricchendo l'ambiente globale per poi
+innescare la valutazione di ogni applicazione di funzione `ExpressionApply`.
+
+20060929-0830 [SoujaK] [[BR]]
+Riguardo a `declare()` e `define()`, esse sono, in realta' parte del meccanismo
+di valutazione, dal momento che, di fatto, si preoccupano della chiamata
+`accept()` sull'espressione parte della definizione. Considerando inoltre che
+l'ambiente e' parte non marginale del processo di valutazione, reputo utile lo
+spostamento dei due metodi all'interno del ''visitor''. [NB: e' necessario
+chiarire se l'accorpamento dei due metodi non precluda l'applicazione di qualche
+strategia (si pensi ai doppi declare... )]
+La proposta e'da inserire nella lista degli enhancment a bassa priorita'.
+
 
 === Iterator ===
 
-200606??-???? [[BR]]
+200606?? [[BR]]
 Gli iterator sono da intendersi come esterni.
 
@@ -230 +274 @@
   gerarchia di espressioni.
 
-
 20060927-2126 [[BR]]
 In merito alla questione iteratori infine si e' deciso di optare per la seconda
@@ -241 +284 @@
 utilizzando gli iteratori sulle entita' pur ignorandone la struttura.
 
-
 == Operazioni aggiunte: `contrib` ==