Når Prolog går galt: Fire almindelige fejl i logisk programmering

Prolog har et strejf af oprørskhed over sig. Mens de fleste udviklere arbejder med imperative eller objektorienterede sprog, vælger Prolog-folk en anden vej. De tænker i relationer og logik i stedet for trin-for-trin-instruktioner. Det er fascinerende – indtil koden pludselig ikke gør, hvad man forventer.

Der er nogle grundlæggende principper, der adskiller velfungerende Prolog-kode fra kode, der bryder sammen i produktion. Bryder man dem, kan man ende med programmer, der enten giver forkerte svar, mangler løsninger eller er umulige at teste. Her er de fire fejl, der går igen hos både nybegyndere og erfarne udviklere.

Den tavse løsningsdræber

Når en Prolog-predicate virker fint med specifikke input, tror man, at det er sikkert at deploye. Men ofte falder koden fra hinanden, når den bliver kaldt med mere generelle variable. Det skyldes typisk, at udvikleren har brugt "urene" konstruktioner som cut (!), if-then-else eller prædikater som var/1.

Disse værktøjer gør det nemt at skrive procedurereelt, but they sacrifice generality. Når man bruger cut til at "optimere", ødelægger man muligheden for backtracking og således får man kun en delmængde af de mulige løsninger.

% Problem: Cut ødelægger muligheden for backtracking
factorial(0, 1) :- !.
factorial(N, F) :-
    N > 0,
    N1 is N - 1,
factorial(N1, F1),
    F is N * F1.

% Når man kører: ?- factorial(N, F).
% Får man kun N = 0, F = 1 og derefter fail – mange valid løsninger går tabt.

En bedre løsning er at bruge dif/2 og højereordens prædikater. Sådan får man koden til at blive både generaliserbar og testbar.

State-mutation – den skjulte afhængighed

Mange Prolog-udviklere opdager assertz/1 og retract/1 og føler sig straks empowered. De kan ændre databasen på runtime. It feels powerful.

Det er også en risiko. Når state ændres globalt, skaber man implicitte afhængigheder. Hvis de prædikater, which mit a run in a different order, bliver eksekveret, kan koden pl