первый метод кажется расточительным, поскольку факты доступны, зачем создавать их список (особенно большой список). Это также должно иметь последствия для памяти, если список достаточно велик?

Да, метод 1 занимает Θ(n) памяти. Его основное преимущество заключается в том, что он является декларативным, то есть имеет прямое логическое значение.

Метод 2, "управляемый отказом цикл", как его называют программисты на Прологе, использует постоянную память, является процедурным и может быть предпочтительным, когда вы все равно делаете процедурные (внелогические) вещи; т. е. в коде ввода-вывода его можно использовать.

Обратите внимание, что в SWI-Prolog есть третий способ записи этого цикла:

forall(season(S), showseason(S)).

Это работает только в том случае, если showseason успешно выполняется для каждой привязки season(S).

Давайте посмотрим на ваш пример. Это очень просто, поэтому мы представим его более сложным. Однако, похоже, вы считаете само собой разумеющимся, что побочные эффекты необходимы. Позвольте мне немного задать вопрос:

В своем примере вы сделали очень интересное открытие: названия всех времен года имеют одинаковую длину. Какое потрясающее понимание! Но подождите, это правда? Самый простой способ проверить это:

?- season(S), atom_length(S,L).
S = spring,
L = 6 ;
S = summer,
L = 6 ;
S = autumn,
L = 6 ;
S = winter,
L = 6.

Не нужно findall/3, не нужно write/1.

При большем количестве ответов визуальный осмотр нецелесообразен. Представьте себе 400 сезонов. Но мы можем проверить это с помощью:

?- season(S), atom_length(S,L), dif(L,6).
false.

Так что мы теперь точно знаем, что сезона другой длины не бывает.

Это мой самый первый ответ на ваш вопрос:

Насколько это возможно, используйте оболочку верхнего уровня, а не собственные процедуры с побочными эффектами! Растяните вещи немного дальше, чтобы полностью избежать побочных эффектов. Это лучший способ избежать циклов, вызванных сбоем, с самого начала.

Есть и другие причины, по которым стоит придерживаться оболочки верхнего уровня:

• Если ваши программы могут быть легко запрошены на верхнем уровне, будет несложно добавить для них тестовые случаи.

• Оболочка верхнего уровня используется многими другими пользователями и поэтому очень хорошо протестирована. Ваше собственное письмо часто ошибочно и непроверено. Подумайте об ограничениях. Подумайте о написании поплавков. Будете ли вы использовать write/1 и для поплавков? Как правильно записывать числа с плавающей запятой, чтобы их можно было точно прочитать? Есть способ сделать это в разделе изо-пролог. Вот ответ:

В ISO writeq/1,2, write_canonical/1,2, write_term/2,3 с опцией quoted(true) гарантируют, что числа с плавающей запятой могут быть точно прочитаны. То есть они одинаковые w.r.t. (==)/2

• Оболочка верхнего уровня показывает вам допустимый текст Prolog. На самом деле ответ сам по себе является вопросом! Его можно вставить обратно на верхний уровень - только чтобы получить тот же самый ответ. Таким образом вы изучите более экзотические, но неизбежные детали Пролога, такие как цитирование, экранирование и заключение в скобки. В противном случае выучить синтаксис практически невозможно, поскольку синтаксические анализаторы Пролога часто чрезвычайно либеральны.

• Ваша программа, скорее всего, будет более доступна для декларативных рассуждений.

Скорее всего, ваши две процедуры methodone и methodtwo неверны: вы забыли новую строку после написания Done. Итак, methodone, methodone содержит искаженную строку. Как это легко проверить?

Но давайте посмотрим немного дальше на вашу программу. Что так типично для циклов, управляемых неудачами, так это то, что они начинаются невинно, как нечто, дающее «только» побочные эффекты, но рано или поздно они также имеют тенденцию привлекать больше семантических частей. В вашем случае atom_length/2 скрыто в цикле, управляемом отказом, совершенно недоступном для тестирования или рассуждений.

Соображения эффективности

Системы Prolog часто реализуют сбой, освобождая стек. Следовательно, циклы, вызванные сбоями, не требуют сборщика мусора. Вот почему люди считают, что циклы, основанные на неудачах, эффективны. Однако это не обязательно так. Для такой цели, как findall(A, season(A), As), каждый ответ на A копируется в некоторое место. Это тривиальная операция для чего-то вроде атома, но представьте себе более крупный термин. Сказать:

blam([]).
blam([L|L]) :- blam(L).

bigterm(L) :- length(L,64), blam(L).

Во многих системах findall/3 или assertz/1 для этого большого термина заморозят систему.

Кроме того, такие системы, как SWI, YAP, SICStus, имеют довольно сложные сборщики мусора. А использование меньшего количества циклов, вызванных сбоями, поможет еще больше улучшить эти системы, поскольку это создает спрос на более сложные методы.

Если уже используется findall, почему бы не использовать и maplist:

findall(S, season(S), L), maplist( showseason, L).

Оба не находятся в чистом логическом ядре Пролога. И да, вы выделяете целый список для всех решений.

Ваш второй метод называется «петля, управляемая отказом», и в нем нет ничего плохого, за исключением того, что нет способа получить предыдущие решения после возврата из-за отказа. Вот почему findall экстралогичен. Внутри это может быть реализовано как цикл, управляемый сбоем, который сохраняет свои промежуточные результаты через утверждение. Таким образом, второй также концептуально чище, помимо того, что не выделяет никакой дополнительной памяти. Обычно он используется в предикатах «драйвера» (то есть пользовательского интерфейса) верхнего уровня.