Срок расширения рабочих процессов

Question

Я добавляю поддержку библиотеки для общих рабочих процессов раскрытия терминов (1). В настоящее время я определил "рабочий" рабочий процесс, в котором наборы правил раскрытия терминов (2) пробуются до тех пор, пока одно из них не выполнится успешно, и "конвейерный" рабочий процесс, в котором результаты расширения из набора правил расширения терминов передаются в следующий набор в конвейере. Интересно, существуют ли другие разумные рабочие процессы расширения терминов, которые, хотя и менее распространенные, имеют практическое применение и поэтому все еще стоят поддержки библиотек.

(1) Для Logtalk текущие версии можно найти по адресу:

https://github.com/LogtalkDotOrg/logtalk3/blob/master/library/hook_pipeline.lgt https://github.com/LogtalkDotOrg/logtalk3/blob/master/library/hook_set.lgt

(2) Набор правил расширения следует понимать в этом контексте как набор предложений для term_expansion/2 пользовательский предикат хука (также возможно goal_expansion/2 определяемый пользователем предикат ловушки, хотя это менее вероятно, учитывая семантику фиксированной точки, используемую для расширения цели), определенную в модуле Prolog или объекте Logtalk (отличном от user псевдо-модуль / объект).

Answer 1

Фиксированная точка - это уже набор и конвейер на определенном уровне во время расширения. Его expand_term/2 является просто транзитивным замыканием одноэтапных предложений term_expansion/2. Но это работает только во время погружения в термин, по моему мнению, нам также нужно что-то при повторной сборке термина.

В редких случаях это транзитивное замыкание даже нуждается в проверке (==)/2, как в некоторых системах Prolog. Скорее всего, он может просто остановиться, если ни один из term_expansions/2 ничего не сделает. Итак, в основном, без проверки (==)/2:

expand_term(X, Y) :- term_expansion(X, H), !, expand_term(H, Y).
expand_term(.. ..) :- /* possibly decend into meta predicate */

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

Это согласуется с некоторыми теориями переписывания терминов, которые говорят: нормальная форма (nf) соединения является функцией нормальной формы его частей. Таким образом, инфраструктура расширения не будет иметь дело с обычными формами, а только предоставит переопределения предикатов, но инфраструктура упрощения будет выполнять обычную работу с формами:

 nf(f(t_1,..,t_n)) --> f'(nf(t_1),..nf(t_n))

Таким образом, крюк упрощения займет f(nf(t_1), .., nf(t_n)), предполагая, что expand_term при переходе в мета-предикат уже дает nf(t_1).. nf(t_n) для мета-аргументов, а затем просто дать f(nf(t_1), .., nf(t_n)) к упрощателю.

Упроститель затем вернется f'(nf(t_1), .., nf(t_n))а именно выполнить свою работу и вернуть упрощенную форму, исходя из предположения, что аргументы уже упрощены. Такой упрощатель может быть довольно мощным. Jekejeke Пролог поставляет такие как этап после расширения.

Упрощенный модуль Jekejeke Prolog и его интеграция в инфраструктуру расширения открыты здесь и здесь. Например, он используется для изменения порядка соединения, вот пример правил для этой цели:

/* Predefined Simplifications */
sys_goal_simplification((  (  A, B), C), J) :-
   sys_simplify_goal((  B, C), H),
   sys_simplify_goal((  A, H), J).

Example:
     (((a, b), c), d) --> (a, (b, (c, d)))

Упроститель Jekejeke Prolog чрезвычайно эффективен, поскольку он может работать с предположением, что он получает уже нормализованные термины. Это не излишне неоднократно будет делать сопоставление с образцом в течение всего данного термина.

Но для написания правил упрощения нужна некоторая общая система переписывания. Правило упрощения должно вызывать упрощение, когда оно создает новый термин.

В приведенном выше примере это два sys_simplify_goal/2 звонки, мы делаем, например, не просто вернуть новый термин с (B,C) в нем, как правило расширения будет делать. поскольку (B,C) не был частью нормализованных аргументов для sys_goal_simplification/2, мы должны сначала нормализовать это.

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

Упрощение Jekejeke Prolog также используется при переписывании предложения прямой цепочки. Там он генерирует из одного прямого предложения несколько предложений дельта-вычисления.

до свидания