Vier valkuilen in Prolog: hoe logica-ontwikkelaars zichzelf in de problemen brengen

Prolog trekt programmeurs aan die graag buiten de gebaande paden denken. Terwijl de rest van de wereld imperatief of objectgeoriënteerd programmeert, kiezen zij voor declaratieve logica. Dat voelt bevrijdend, maar het leidt ook tot een paar hardnekkige fouten.

Wie deze valkuilen vermijdt, bouwt stabiele en onderhoudbare code. Wie ze over het hoofd ziet, krijgt programma's die onverwachte resultaten geven of volledig stilvallen.

De stille moordenaar van oplossingen

Veel ontwikkelaars testen hun predikaten met concrete waarden en zijn tevreden. Zodra iemand een bredere vraag stelt, blijkt het predikaat ineens niets meer terug te geven.

De boosdoeners zijn vaak constructies zoals de cut (!), if-then-else en typecontroles zoals var/1. Ze maken code sneller te schrijven, maar breken de declaratieve kracht van Prolog. Een predikaat dat alleen werkt als alle variabelen al gebonden zijn, verliest zijn nut als relation.

Gebruik in plaats daarvan schone datastructuren en constraint-predikaten zoals dif/2. Zo blijft je code algemeen en goed te testen.

De valstrik van databasewijzigingen

assertz/1 en retract/1 lijken krachtig. Je kunt het kennisbestand tijdens runtime aanpassen en zo flexibele programma's bouwen.

In de praktijk ontstaat er een verborgen afhankelijkheid. De volgorde van predikaten bepaalt of alles nog werkt, maar die volgorde staat nergens expliciet beschreven. Tests laten sporen achter die het volgende testgeval verstoren.

De oplossing is eenvoudig: laat toestand door argumenten lopen in plaats van door de globale database.

De presentatiefout

Sommige predikaten doen meer dan ze zouden moeten. Ze berekenen een oplossing en printen het resultaat meteen weg.

solve_and_print :-
    solution(S),
    format("The solution is: ~q~n", [S]).

Zo'n predikaat kun je niet hergebruiken. Je kunt het niet testen als een echte relatie. Het resultaat verdwijnt in de terminal en wordt geen Prolog-term die je verder kunt gebruiken.

Maak een duidelijk onderscheid: beschrijf de oplossing eerst puur declaratief. Pas daarna laat je de top-level of een DCG de presentatie regelen.

Oudere constructies die je beter kunt vermijden

Prolog heeft zich ontwikkeld. Tools zoals CLP(FD) bestaan al twintig jaar en maken code duidelijker en sterker dan de klassieke rekenoperatoren.

Desondanks blijven veel mensen is/2, =:=/2 en >/2 gebruiken. Dat maakt code moeilijker te begrijpen, vooral voor beginners. Het vermengt declaratieve bedoeling met operationele details.

Met constraints lees je code als een specificatie. 而不是 als een procedure.

Een voorbeeld: de horror-factorial

Een combinatie van de vier problemen ziet er zo uit:

horror_factorial(0, 1) :- !.
horror_factorial(N, F) :-
    N > 0,
    N1 is N - 1,
    horror_factorial(N1, F1),
    F is N * F1.

Dit predikaat werkt alleen als N al bekend is. Het levert één resultaat op en dan stopt het. Het bréékt bij een algemene query omdat het drie van de vier valkuilen bevat: een cut, lage rekenoperatoren en een beperkte declaratieve scope.

Hoe je Prolog-code sterker maakt

Om Prolog-code te bouwen die echt werkt, volg je een paar eenvoudige regels:

• Gebruik declaratieve patronen en constraints in plaats van cuts en typechecks.
• Laat toestand expliciet meelopen via argumenten.
• Scheid de logica van de presentatie.
• Gebruik moderne tools zoals CLP(FD)。

Zo wordt je code een echte specificatie die je kunt queryen en testen. Prolog laat dan eindelijk zijn volledige kracht zien.