Capitolo 5: Algol 60, Pascal e C
Algol 60 (58-63) -Backus, McCarthy -fino al Pascal (70) è stato lo standard accademico punti positivi -BNF!! -block structure (begin-end), recursion, higher order functions, stack storage, meno restrizioni punti negativi -all related with parameter passing: procedure as parameters, arrays without bounds, pass-by-name (beta-riduzione)
esempio di funzione Algol real procedure average(a,n); real array A; integer n; begin real sum; sum:=0; for i=1 step 1 until n do sum:=sum + A[i]; average:=sum/n end;
esercizio 5.1: passaggio di funzioni è unsafe il tipo di Q è semplicemente proc e questo non basta per evitare errori di tipo a run-time proc P(proc Q) begin Q(true) end; P(H); proc H(i) integer i; begin H:=i+3 end;
pass-by-name => in-lining della funzione con le espressioni dei parametri attuali sostituiti ai corrispondenti formali Algol 60 copy rule strani side effects tra i parametri formali c è anche pass-by-value, ma ineffiiciente con array
esempio di pass-by-name in Algol 60: begin integer i; integer procedure sum(i,j); integer i, j; begin integer sm; sm:=0; for i:= 1 step 1 until 100 do sm:= sm+j; sum:=sm end; print(sum(i,i*10)) end vedere es. 5.2
copy rule: begin integer sm; sm:=0; for i:= 1 step 1 until 100 do sm:= sm+i*10; sum:=sm end; sm = 1*10+ 2*10+ 3*10+ +100*10
Algol 68 basato su un formalismo di specifica chiamato grammatiche a 2 livelli deriva dal successo del BNF per specificare la sintassi si voleva grammatica estesa per specificare anche la semantica del LP
Pascal definito negli anni 70 da Nyklaus Wirth Algorithms+Data Structures = Programs (75) uno dei linguaggi più diffusi fino negli anni 90 (anche per SO Mac) concetti per definire strutture dati: array, record, record con varianti, tipi subrange [1..10] al più funzioni di ordine 2
problema con gli array che hanno tipo: A: array <tipo indice> of <tipo degli elementi> A: array [-10..10] of integer; quando lo passo ad una funzione: procedure P(a:array[-10..10] of integer) P funziona solo per array di questo tipo!! non esiste array [n..m] of int con variabili
C (69-73) Dennis Ritchie Unix deriva da linguaggio senza tipi (B e prima BCLP) modello della memoria come sequenza di parole aritmetica dei puntatori array e puntatori sono la stessa cosa: tipi si confondono cast la debolezza dei tipi nei 70 era un pregio, ma successivamente come un fatto negativo (C++)
Capitolo (4.4.2) imperativo dichiarativo
linguaggi imperativi e linguaggi dichiarativi: imperativo: l assegnazione x=x-1; è un ordine al computer di modificare l r-valore di x dichiarativo: invece int f(int y){return y-1;} dichiara che f è una funzione con un certo grafo: {(n,n-1) n Z}
Lisp ed ML NON sono linguaggi dichiarativi, permettono di fare assegnazioni solo escludendo queste parti si ottengono Linguaggi funzionali puri = dichiarativi
Linguaggi dichiarativi l essenza del calcolo consiste nel valutare espressioni che contengono invocazioni a funzioni l assenza di variabili modificabili => le funzioni non hanno side-effects
test di purezza: all interno di un dato blocco in cui sono visibili le variabili x1 xn, se invocassimo f(x1,,xn)+f(x1,,xn)+f(x1,,xn) il risultato di ogni invocazione di f è sempre lo stesso f has no side effects
referential transparency: in linguistica si usa per indicare il fenomeno in cui un termine può essere sostituito con un altro mantenendo inalterato il significato della frase i linguaggi funzionali puri supportano la referential transparency, mentre quelli imperativi no (o meno) il punto è che è più facile trovare cose equivalenti nei linguaggi funzionali puri che in quelli imperativi 2 esempi di cose
referential tranparency and variables i linguaggi funzionali puri la supportano se x ha lo stesso valore di y, allora E( x ) è equivalente a E( y ) i linguaggi imperativi la supportano solo se x e y sono alias nei linguaggi funzionali puri una variabile è solo un nome associato ad un valore costante
referential transparency and functions: linguaggi funzionali puri : 2 funzioni sono equivalenti se hanno lo stesso grafo per i linguaggi imperativi: se hanno lo stesso grafo e gli stessi side effects risultato F funzionale pura risultato F imperativa side effect
declarative is better than imperative? Nel 1977 John Backus (inventore di Fortran e Algol 60) sostenne che i linguaggi funzionali puri sono: più facili da capire degli imperativi sono più astratti, cioè più indipendenti dalla realizzazione delle strutture dati più efficienti la referential transparency l esecuzione concorrente di parti del programma
Backus capì che era essenziale produrre SW il più corretto e facile da mantenere e modificare possibile pensò che la soluzione fossero i linguaggi funzionali appunto più semplici e astratti e ne propose e sviluppò uno: FP
imperativo: int prod=0; for(int i=0;i<n;i++) prod=prod+a[i]*b[i]; funzionale: In_prod=(Fold +). (ApplyToAll *).Transpose
non è andata così -soluzioni funzionali sono + astratte, ma le cose astratte non sono + facili -parallelismo non è (ancora) facile da usare -inerzia del mercato -paradigma ad oggetti vincente -ma recentemente linguaggi che mescolano parti funzionali e parti ad oggetti: Python, Ruby