Особенности хорошего кода Пролога?

Question

Какую эвристику дизайна нужно освоить, чтобы написать хороший Пролог? Я слышал, что опытному программисту требуется около двух лет, чтобы стать опытным в Прологе. Эффективное использование рекурсии является частью этого, но это, кажется, относительно небольшое препятствие. Что именно доставляет программистам столько проблем? Что я должен искать в примере кода, чтобы оценить его качество?

Answer 1

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

Чистый, монотонный код. Этот код лежит в основе Пролога. В таком коде содержится много алгебраических свойств, и реальные проблемы описываются в чистом идеальном виде, с которым часто рекламируется Prolog. Тем не менее, даже в таких частях могут появляться определенные процедурные свойства, такие как отсутствие завершения. Возьмите в качестве примера коммутативность соединения. В чистом монотонном коде ( A, B ) а также ( B, A ) опишите такое же отношение. Единственные различия могут заключаться в различном поведении завершения и последовательности появления ответов. В идеале имена чистых предикатов сообщают, что предикаты являются отношениями. Императивы определенно не являются хорошим выбором здесь.

Побочный эффект кода. Другая крайность - это код, который можно понять, только эффективно выполнив его либо машиной, либо умом. В программе нет простых инвариантов. Но даже в таких местах могут сохраняться определенные свойства, такие как стойкость. Фактически такой код мало чем отличается от других языков программирования.

Часто побочные эффекты "съедают" чистую сторону, поскольку программисты привыкли к императивному, командно-ориентированному принципу "сделай это". Чтобы склониться в другом направлении, подумайте, какие свойства вы потеряете или приобретете. Подумайте, как легко будет протестировать вашу программу: чем чище программа, тем проще ее тестировать без лишней песочницы. Простой запрос верхнего уровня достаточно хорош.

Некоторые примеры того, как чистая сторона может быть расширена за счет, казалось бы, необходимых побочных эффектов:

• Каковы плюсы и минусы использования ручной итерации списка по сравнению с рекурсией через сбой

• Prolog Recursion пропускает те же результаты

Или просто эти ответы.

Редактировать: в вашем комментарии вы просите "совет для обучения". Итак, вот некоторые:

1. Придерживайтесь написания только монотонного кода. Вы можете судить, чтобы выбрать одну или другую сторону, если вы знаете оба. Я предполагаю, что у вас есть некоторый предыдущий опыт создания побочных эффектов в каком-то командно-ориентированном языке, но ни одного из них с чистым кодом. Как следствие, это будет означать, что вы будете воздерживаться от написания немонотонного кода.

2. Играть с верхнего уровня. Представьте, что уровень доступа - это единственный способ получить доступ к вашим программам. Как бы вы сформулировали проблему так, чтобы она вписывалась в этот формат? Уровень SWI был специально разработан для обеспечения такого легкого взаимодействия.

3. Используйте clpfd для арифметики. Не использовать (is)/2это делает ваш код слишком модным.

4. Наслаждайтесь алгебраическими свойствами чистого монотонного кода. Подумайте об этом: вы добавляете цель, где бы вы ни находились, и все же вы можете предсказать, что эта цель будет специализировать вашу программу (и в лучшем случае оставить ее как есть). Вы можете - вслепую - удалить цель, и все же вы знаете (часть) ее эффект.

5. Изучите понятие отказа-слитка, чтобы освоить не прекращение.

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

7. Следи за языком. То, как вы говорите о программе, влияет на то, как вы думаете об этом. Таким образом, если вы используете много операционализирующего языка (например: это делает это и т. Д.), Скорее всего, вы усиливаете командно-ориентированное представление. Есть более чистый способ говорить о вещах, но вам нужно его найти. Это, наверное, самая сложная часть.