Атрибутивные переменные: библиотечные интерфейсы/реализации/переносимость

Когда я просматривал некоторые prolog в последнее время я наткнулся на этот ответ @mat на вопрос Как представлять направленный циклический граф в Prolog с прямым доступом к соседние вершины.

До сих пор мой личный опыт использования атрибутов в Prolog был очень ограниченным. Но прецедент, данный @mat, вызвал мой интерес. Поэтому я попытался использовать его для ответа на другой вопрос, список заказов с программированием логики ограничений.

Во-первых, хорошие новости: мое первое использование атрибутивных переменных получилось так, как я хотел.

Тогда, не очень хорошая новость: когда я отправил ответ, я понял, что в Prolog существует несколько API и реализации для атрибутов.

Я чувствую, что над моей головой здесь... В частности, я хочу знать следующее:

Какой API используется в широком распространении? До сих пор я нашел два: SICStus и SWI.
Какие функции предлагают различные атрибутивные варианты реализации? Те же самые? Или один из них используется в другом?
Существуют ли различия в семантике?
Как насчет фактической реализации? Являются ли более эффективными, чем другие?
Может (или есть) использовать атрибутивные переменные в качестве переносимости?

Много вопросительных знаков, здесь... Пожалуйста, поделитесь своим опытом/позицией? Заранее благодарю вас!

Изменить 2015-04-22

Здесь приведен фрагмент кода ответа :

init_att_var(X,Z) :-
    put_attr(Z,value,X).

get_att_value(Var,Value) :-
    get_attr(Var,value,Value).

До сих пор я "использовал" put_attr/3 и get_attr/3, но --- согласно документации SICStus Prolog по атрибутам переменные --- SICStus предлагает put_attr/2 и get_attr/2.

Таким образом, даже этот очень мелкий случай использования требует некоторого уровня эмуляции (так или иначе).

Ответ 1

Я хотел бы сосредоточиться на одной важной общей точке, которую я заметил при работе с различными интерфейсами для переменных атрибутов: при разработке интерфейса для атрибутов переменных разработчик должен также иметь в виду следующее:

Можно ли учитывать атрибуты при рассуждении о одновременных унификациях, как в [X,Y] = [0,1]?

Это возможно, например, в SICStus Prolog, поскольку такие привязки отменены до вызова verify_attributes/3. В интерфейсе, предоставленном hProlog (attr_unify_hook/2, называемом после унификации и со всеми привязанностями уже на месте), трудно учесть (предыдущие) атрибуты Y, когда рассуждения о объединение X в attr_unify_hook/2, потому что Y уже не является переменной в этой точке! Этого может быть достаточно для решателей, которые могут принимать решения, основанные только на наземных значениях, но это серьезное ограничение для решателей, которые нуждаются в дополнительных данных, обычно хранящихся в атрибутах, чтобы увидеть, должно ли объединение быть успешным, и которые затем более не доступны, Один очевидный пример: логическая унификация с диаграммами решений.

По состоянию на 2016 год проверка-атрибуты ветвь в SWI-Prolog также поддерживает verify_attributes/3, благодаря большая работа по выполнению Дуглас Майлз. Филиал готов к тестированию и должен быть объединен с мастером, как только он будет работать правильно и эффективно. Для совместимости с hProlog ветка также поддерживает attr_unify_hook/2: она делает это, переписывая такие определения в более общий verify_attributes/3 во время компиляции.

Понятно, что может быть недостаток verify_attributes/3, поскольку одновременное создание нескольких переменных может привести к тому, что вы скорее увидите (в attr_unify_hook/2), что объединение не может быть выполнено. Тем не менее, я с удовольствием и в любое время обмениваюсь этим, как правило, незначительным преимуществом для повышения надежности, простоты использования и расширенной функциональности, которую дает вам более общий интерфейс, и который в любом случае уже является стандартным поведением в SICStus Prolog, который находится на вершине его общности также является одной из более быстрых систем Prolog.

SICStus Prolog также содержит важный предикат, называемый project_attributes/2: он используется toplevel для ограничений проекта для запроса переменных. SWI-Prolog также поддерживает это в последних версиях.

Существует также огромное преимущество интерфейса SWI: остаточные цели, которые attribute_goals//1 и, следовательно, copy_term/3 дают вам, всегда являются списком. Это помогает пользователям избегать дефолтности в своем коде и поощряет более декларативный интерфейс, потому что список целей чистого ограничения не может содержать структуры управления.

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

Другие предикаты интерфейса для присваиваемых переменных в большинстве случаев легко взаимозаменяемы с простыми предикатами оболочки для разных систем.

Ответ 2

Jekejeke Minlog имеет переменные атрибута состояния <или > . Ну не совсем, переменная атрибута может иметь нуль, один или много крючков, которым разрешено закрывать, и, следовательно, может нести небольшое состояние.

Но обычно реализация управляет состоянием. Для этого Цель Jekejeke Minlog позволяет создавать ссылочные типы из переменных, так что они могут использоваться как индексы в таблицах.

Полный потенциал развязан, если он сочетается с трейлингом и/или вперед. В качестве примера мы реализовали CLP (FD). Существует также небольшая обучающая программа.

В нашем случае примитивные компоненты:

1) Переменные атрибутов без состояний
2) Трейлинг и переменные ключи
3) Продолжение очереди

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

Перед реализацией приложений есть несколько дополнительных уровней, которые в основном являются скоплениями примитивов для внесения изменений временно.

Основными приложениями пока являются open source здесь и здесь:

a) Конечный решатель ограничений домена
б) Гербрандские ограничения
c) Подвеска цели

Bye

Ответ 3

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

Основные характеристики этой конструкции:

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

Этот документ (раздел 4) и документация ECLiPSe содержат более подробную информацию.

Ответ 4

Дополнительная перспектива для атрибутивных библиотек переменных - это то, сколько атрибутов может быть определено для каждого модуля. В случае SWI-Prolog/YAP и цитирования документации SWI:

Каждый атрибут связан с модулем, а крючок (attr_unify_hook/2) выполняется в этом модуле.

Это серьезное ограничение для разработчиков библиотек, таких как CLP (FD), поскольку оно заставляет использовать дополнительные модули с единственной целью - иметь несколько атрибутов вместо того, чтобы определять столько атрибутов, сколько требуется в модуле, реализующем их библиотеку. Это ограничение не существует на интерфейсе SICStus Prolog, который предоставляет директиву attribute/1, которая позволяет объявлять произвольное количество атрибутов для каждого модуля.