Capitolo 5: Algol 60, Pascal e C

Transcript

1 Capitolo 5: Algol 60, Pascal e C

2 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)

3 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;

4 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;

5 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

6 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

7 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

8 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

9 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

10 problema con gli array che hanno tipo: A: array <tipo indice> of <tipo degli elementi> A: array [ ] of integer; quando lo passo ad una funzione: procedure P(a:array[ ] of integer) P funziona solo per array di questo tipo!! non esiste array [n..m] of int con variabili

11 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++)

12 Capitolo (4.4.2) imperativo dichiarativo

13 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}

14 Lisp ed ML NON sono linguaggi dichiarativi, permettono di fare assegnazioni solo escludendo queste parti si ottengono Linguaggi funzionali puri = dichiarativi

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 imperativo: int prod=0; for(int i=0;i<n;i++) prod=prod+a[i]*b[i]; funzionale: In_prod=(Fold +). (ApplyToAll *).Transpose

23 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