La maggiore difficoltà nella scrittura del buon codice Prolog consiste non solo nella comprensione, ma anche nella trasmissione adeguata dell'intenzione o dello scopo di un programma. A differenza di altri linguaggi di programmazione, esistono spesso diversi tipi di codice Prolog all'interno dello stesso programma. Confondendo tali livelli si verificano bug e problemi:
Codice monotonico puro. Questo codice si trova nel cuore di Prolog. In tale codice ci sono molte proprietà algebriche e i problemi reali sono descritti nel modo puro e ideale con cui spesso viene pubblicizzato Prolog. Tuttavia, anche in tali parti possono emergere alcune proprietà procedurali, come la mancata risoluzione. Prendiamo ad esempio la commutatività della congiunzione. Nel puro codice monotonico, (A, B) e (B, A) descrivono la stessa relazione. Le uniche differenze possono risiedere nel comportamento di terminazione diverso e nella sequenza di visualizzazione delle risposte. Idealmente, i nomi dei predicati puri comunicano che i predicati sono relazioni. Gli imperativi non sono sicuramente una buona scelta qui.
Codice effetto-laterale. L'altro estremo è il codice che può essere compreso solo eseguendolo efficacemente, sia dalla macchina che dalla mente. Non ci sono invarianti semplici nel programma. Ma anche in tali parti, potrebbero ancora esserci certe proprietà osservate come costanza. In effetti tale codice non è molto diverso dagli altri linguaggi di programmazione.
Spesso, la parte con effetti collaterali "mangia" il lato puro poiché i programmatori sono abituati a un pensiero imperativo e orientato al comando. Per inclinarti nella direzione opposta, pensa a quali proprietà perderai o guadagnerai. Pensa a quanto sarà facile testare il tuo programma: più puro è un programma, più facile è provare senza sandbox in più. Una semplice query di livello superiore è abbastanza buona.
Alcuni esempi, come il lato puro può essere ampliato a spese del apparentemente necessarie effetti collaterali:
O semplicemente these answers.
Modifica: nel tuo commento, chiedi "consigli per l'apprendimento". Quindi ecco alcuni:
Stick per scrivere solo codice puro, monotono. Puoi solo giudicare di scegliere l'uno o l'altro lato se conosci entrambi. Presumo che tu abbia qualche precedente esperienza nella produzione di effetti collaterali in qualche linguaggio orientato ai comandi, ma nessuno con codice puro. Di conseguenza, ciò significa che ti asterrai dal scrivere codice intrinsecamente non monotono.
Gioca con il livello superiore. Immagina, il toplevel è l'unico modo per accedere ai tuoi programmi. Come formulare un problema in modo tale che si adatti a questo formato? Il toplevel SWI è stato specificamente progettato per consentire un'interazione così leggera.
Utilizzare clpfd per aritmetica. Non usare (is)/2, rende il tuo codice troppo modesto.
Godetevi le proprietà algebriche del codice puro e monotono. Pensaci: aggiungi un obiettivo, non importa dove, e comunque puoi prevedere che questo obiettivo specializzerà il tuo programma (e nel migliore dei casi lo lascerà così com'è). Puoi - ciecamente - rimuovere un obiettivo, e tuttavia conosci (o parte) il suo effetto.
Studio della nozione di failure-slice per il master non di terminazione.
Non utilizzare un tracciante/debugger passo passo, come è offerto in molti Prolog. Ti mostra solo i passi precisi che Prolog prende. Non mostra nulla direttamente correlato al significato del programma. Rafforza un pensiero passo-passo.
Guarda la tua lingua. Il modo in cui parli di un programma influenza il tuo modo di pensarci. Quindi, se usi un sacco di linguaggio operativo (come: Questo fa questo ecc.), È probabile che tu rinforzi la vista orientata ai comandi. C'è un modo più pulito di parlare delle cose, ma è necessario trovarlo. Questa è probabilmente la parte più difficile.
Per i 2 anni [vedere questa raccomandazione] (http://norvig.com/21-days.html) - e non si tratta nemmeno di Prolog! – false