Questo sito utilizza cookie di terze parti per inviarti pubblicità in linea con le tue preferenze. Se vuoi saperne di più clicca QUI 
Chiudendo questo banner, scorrendo questa pagina, cliccando su un link o proseguendo la navigazione in altra maniera, acconsenti all'uso dei cookie. OK

Elaborazione e interazione in programmazione logica e ad oggetti

In questo lavoro verrà presentato un modello di basso livello più espressivo della macchina di Turing (TM) in quanto vi aggiunge due dimensioni: Stato e Interazione. Tale modello sarà proposto come descrittivo della Object Oriented Programming (OOP) per la quale la TM risulta invece insufficiente. Vedremo anche come questo sia riconducibile, ad un più alto livello di astrazione, ad una precisa strutturazione dei programmi che ne mette in evidenza le componenti essenziali. Questi risultati verranno poi sfruttati per definire una macchina astratta che integri il modello della programmazione logica (LP) e quello della OOP.

Mostra/Nascondi contenuto.
Parte Prima Logic Programming e Object Oriented Programming Ciò che alla fine deve contrarsi all’inizio deve espandersi. Ciò che alla fine deve indebolirsi all’inizio dev’essere forte. Ciò che alla fine dev’essere scartato all’inizio deve essere abbracciato. Ciò che alla fine dev’essere ottenuto all’inizio deve essere dato. Ecco ciò che si chiama un’intuizione sottile. Lao Tzu, Tao te Ching Vi sono tre classi di linguaggi di programmazione: imperativi (Pascal, C, …), funzionali (Lisp, Scheme, …), logici (Prolog, …). Il paradigma ad oggetti può essere considerato ortogonale a questi e quindi applicato ad ognuno di tali modelli, ma di solito con OOP (Object Oriented Programming) si fa implicitamente riferimento alla programmazione ad oggetti in ambito imperativo ed a linguaggi come C++, java, ecc. Anche noi useremo il termine OOP con tale significato. Non è infatti un caso che praticamente gli oggetti vengano applicati solamente al modello imperativo mentre per i linguaggi funzionali e logici le proposte di estensione con oggetti sono rimaste per lo più in ambiente accademico con limitati usi in ambito industriale e comunque non confrontabili con quelli della OOP imperativa. Uno dei motivi è il fatto che nel modello funzionale ed in quello logico non vi è il concetto di stato permanente 1 . Ma non è forse vero, come sempre si dice, che per computare non abbiamo bisogno di effetti collaterali (modifiche di stato)? Lasciamo per il momento in sospeso tale domanda perché ne parleremo estesamente durante tutto il lavoro. Sottolineiamo poi che mentre nei linguaggi funzionali l’introduzione del concetto di oggetto è semplice e naturale grazie alle chiusure che realizzano già l’incapsulamento (basta quindi rendere le variazioni permanenti), il concetto di oggetto sembra fortemente in contrasto con il modello logico. Se si osservano tutte le proposte si vedrà che l’introduzione degli oggetti in logica (del primo ordine) forzano tale modello facendo in modo che non si possa più parlare di modello logico; oppure passano ad altre logiche non del primo ordine e tra questo quello della logica lineare sembra essere la più promettente. Ribadiamo però che il paradigma ad oggetti è ortogonale alle classi dei linguaggi di programmazione e la forzatura del modello logico nasce dal fatto che si tenta di applicare il modello ad oggetti dei linguaggi imperativi. Nell’ultima parte proporremo 1 Al posto dello stato permanente si possono usare meccanismi equivalenti, non è importante il concetto di stato e di effetti collaterali quanto quello di permanenza.

Tesi di Laurea

Facoltà: Ingegneria

Autore: Tiziano Moretti Contatta »

Composta da 233 pagine.

 

Questa tesi ha raggiunto 1380 click dal 20/03/2004.

 

Consultata integralmente una volta.

Disponibile in PDF, la consultazione è esclusivamente in formato digitale.