Четирите основни грешки в Prolog програмирането

Prolog привлича с нестандартния си подход. Докато повечето разработчици работят с императивни или обектно-ориентирани езици, Prolog предлага декларативен стил, който променя начина, по който мислим за задачите. Това е интересно, докато кодът не започне да се държи неочаквано.

Няколко основни правила отделят стабилния Prolog код от този, който създава проблеми на практика. Когато ги нарушим, получаваме предсказуемо поведение — или грешки, или липсващи решения. Ето четирите най-често срещани грешки.

Скритият убиец на решения

Често се случва да напишем предикат, който работи добре с конкретни стойности. Но когато някой направи по-обща заявка, резултатите изчезват.

Причината обикновално е използването на „нечисти“ конструкции — оператора cut (!), условни изрази като ->, или проверка на типа с var/1. Те опростяват нещата при процедурно мислене, но унищожават декларативната природа на Prolog.

% Проблемно: използване на cut за „оптимизация“
factorial(0, 1) :- !.
factorial(N, F) :-
    N > 0,
    N1 is N - 1,
    factorial(N1, F1),
    F is N * F1.

При заявка ?- factorial(N, F). получаваме само едно решение — и после неуспех. Вместо това използвайте dif/2, constraint предикати и мета-предикати. Кодът става по-общ и лесен за тестване.

Промяна на базата данни по време на изпълнение

Много разработчици се увличат по assertz/1 и retract/1. Те дават усещане за мощ и контрол — но на практика създават скрити зависимости.

Когато променяме глобалното състояние по време на изпълнение, кодът става крехък. Предикати зависят от състояние, което не се вижда в аргументите. Тестовете се объркват,因为 следващият тестов пример може да остави боклук в базата.

Алтернативата е проста: предавайте състоянието явно чрез аргументи. Това прави логиката прозрачна и независима от реда на изпълнение.

Смесване на логиката с печатане

Една честа грешка е да се включват странични ефекти в предикати, което блокова тестването и рециклирането на кода.

% Проблемен пример
solve_and_print :-
    solution(S),
    format("The solution is: ~q~n", [S]).

Този предикат не може да се тества лесно. Не може да се рециклира. Топ-левелът трябва да отговаря за представянето на резултатите, а предикатът — само за описанието на логиката. Може да използвате DCG нотация за декларативно форматиране.

Използване на остарели конструкции

Prolog се развива. CLP(FD) съществува от над два десетилетия, но някои разработчици продължът да използват (is)/2, (=:=)/2 и (>)/2 „заща те са работили досега“.

Това прави кода по-труден за разбиране и за научаване. С CLP(FD) логиката става по-ясна и кодът чете като спецификация, а не като процедура.

Пример: факториел с всички грешки

% Проблематична версия
horror_factorial(0, 1) :- !.
horror_factorial(N, F) :-
    N > 0,
    N1 is N - 1,
    horror_factorial(N1, F1),
    F is N * F1.

Това нарушава три принципа наведнъж:

• cut прекъсва възможността за backtracking
• нискостепенни аритметични предикати изискват конкретни стойности
• кодът работи като функция, но не като връзка

При заявка ?- horror_factorial(N, F). получаваме само едно решение.

Как да пишем по-добър Prolog код

За да избегнем проблемите:

• Използвайте декларативни конструкции — constraints и мета-предикати вместо cut и type checks.
• Предавайте състоянието явно чрез аргументи.
• Разделяйте логиката от представянето.
• Прилагайте съвременни инструменти като CLP(FD).

Кодът трябва да отговаря на най-общите заявки и да чете като спецификация. Тогава Prolog показва истинските си възможности.