Cechy dobrego kodu Prolog?

Question

Jakie są heurystyki projektowania, które trzeba opanować, aby pisać dobre Prolog? Słyszałem, że potrzeba doświadczonego programisty około dwóch lat, aby stać się biegły w Prologu. Skuteczna rekursja jest jej częścią, ale wydaje się to stosunkowo niewielką przeszkodą. Co dokładnie sprawia, że ​​programiści mają tyle problemów? Czego powinienem szukać w przykładowym kodzie, aby ocenić jego jakość?

Answer 1

Główną trudnością w napisaniu dobrego kodu Prologu jest nie tylko zrozumienie, ale także odpowiednie przekazywanie intencji lub celu programu. W przeciwieństwie do innych języków programowania istnieje kilka zupełnie różnych rodzajów kodu Prolog często w tym samym programie. Przez pomylenie takich poziomów pojawiają się błędy i problemy:

Czysty, monotoniczny kod. Ten kod leży w sercu Prolog. W takim kodzie wiele własności algebraicznych utrzymuje, a rzeczywiste problemy są opisane w czysty, idealny sposób, z którym często reklamuje się Prolog. Jednak nawet w takich częściach mogą pojawić się pewne właściwości proceduralne, takie jak brak zakończenia. Weźmy jako przykład przemienność koniunkcji. W czystym, monotonicznym kodzie, (A, B) i (B, A) opisują tę samą relację. Jedyne różnice mogą wynikać z różnych zachowań kończących i sekwencji odpowiedzi. Idealnie, nazwy czystych predykatów komunikują, że predykaty są relacjami. Imperatywy zdecydowanie nie są dobrym wyborem tutaj.

Kod poboczny. Drugą skrajnością jest kod, który można zrozumieć tylko przez skuteczne wykonanie go, albo przez maszynę, albo w umyśle. W programie nie ma prostych niezmienników. Ale nawet w takich częściach mogą nadal występować pewne właściwości, takie jak niezłomność. Skutecznie taki kod nie różni się zbytnio od innych języków programowania.

Często część poboczna "zjada" czystą stronę, ponieważ programiści są przyzwyczajeni do imperatywnego, zorientowanego na polecenia, do-tego do-tego myślenia. Aby pochylić się w przeciwnym kierunku, zastanów się, które właściwości stracisz lub zyskasz. Pomyśl, jak łatwo będzie przetestować Twój program: Im bardziej przejrzysty program, tym łatwiej go przetestować bez dodatkowej piaskownicy. Prosta kwerenda tweenvel jest wystarczająco dobra.

Niektóre przykłady, jak czysta strona może zostać rozbudowany kosztem pozornie niezbędnych działań niepożądanych:

• What are the pros and cons of using manual list iteration vs recursion through fail

• Prolog Recursion skipping same results

Albo po prostu these answers.

Edytuj: W swoim komentarzu pytasz o "porady dotyczące nauki". Oto kilka:

1. Trzymaj się wyłącznie czystego, monotonicznego kodu. Możesz osądzić wybór jednej lub drugiej strony, jeśli znasz oba. Zakładam, że masz pewne wcześniejsze doświadczenia w wytwarzaniu efektów ubocznych w niektórych językach zorientowanych na polecenia, ale żaden z czystym kodem. W konsekwencji będzie to oznaczać, że powstrzymasz się od pisania z natury niemonotonicznego kodu.

2. Graj za darmo. Wyobraź sobie, że jedyny sposób na uzyskanie dostępu do programów. Jak sformułujesz problem, który pasuje do tego formatu? Projekt SWI został opracowany specjalnie w celu umożliwienia tak lekkiej interakcji.

3. Użyj clpfd dla arytmetyki. Nie używaj (is)/2, to sprawia, że ​​twój kod jest zbyt skromny.

4. Ciesz się algebraicznymi właściwościami czystego, monotonicznego kodu. Pomyśl o tym: dodajesz cel, bez względu na to gdzie, a mimo to możesz przewidzieć, że ten cel będzie specjalizować twój program (i co najwyżej pozostawia go tak, jak jest). Możesz - na ślepo - usunąć cel, a nadal wiesz (część) jego efekt.

5. Przestudiuj pojęcie o failure-slice, aby opanować nieterminację.

6. Nie należy używać krok po kroku śledzenia/debuggera, ponieważ jest on oferowany w wielu Prologach. Pokazuje tylko dokładne kroki, które podejmuje Prolog. Nie pokazuje niczego bezpośrednio związanego ze znaczeniem programu. Wzmacnia to krok po kroku.

7. Obserwuj swój język. Sposób, w jaki mówisz o programie, wpływa na sposób myślenia o nim. Tak więc, jeśli używasz dużo języka operacjonalizującego (jak: To robi to itp.), Istnieje szansa, że ​​wzmocnisz zorientowany na polecenia widok. Istnieje czystszy sposób mówienia o rzeczach, ale musisz go znaleźć. To chyba najtrudniejsza część.