tutorial reglas introduccion inteligencia explicados estructura ejercicios caracteristicas artificial prolog iso-prolog

reglas - ¿Cuáles son las mejores prácticas de programación y pautas de estilo de Prolog?



prolog tutorial (1)

Para diseñar interfaces limpias en Prolog, recomiendo leer el estándar Prolog, vea iso-prolog .

En particular, el formato específico de codificación de predicados integrados que incluye un estilo particular de documentación, pero también la forma en que se señalan los errores. Consulte 8.1 El formato de las definiciones de predicados incorporados de ISO / IEC 13211-1: 1995. Encontrará las definiciones en ese estilo en línea en Cor.2 y el prólogo de Prolog .

Un muy buen ejemplo de una biblioteca que sigue las convenciones de señalización de error ISO hasta la letra (y aún no está estandarizada) es la implementación de la library(clpfd) en SICStus y SWI. Si bien ambas implementaciones son fundamentalmente diferentes en su enfoque, utilizan las convenciones de error para su mejor ventaja.

De vuelta a ISO. Este es el formato de ISO para los predicados incorporados:

xyz Nombre / Arity

Al principio, puede haber una breve observación informal opcional.

xyz1 Descripción

Se proporciona una descripción declarativa que comienza muy a menudo con el objetivo más general utilizando nombres descriptivos de las variables para que puedan consultarse más adelante. Si el significado del predicado no es declarativo en absoluto, se afirma que "es verdadero" o se usa alguna palabra operacional innecesaria como "unifica", "ensambla". Déjame dar un ejemplo:

8.5.4 copy_term / 2

8.5.4.1 Descripción

copy_term(Term_1, Term_2) es verdadero si Term_2 unifica con un término T que es una copia renombrada (7.1.6.2) de Term_1 .

Entonces, esto unifica es una gran señal de advertencia roja: nunca pienses que este predicado es una relación, solo puede ser entendido procesalmente. Y aún más (implícitamente) afirma que la definición es firme en el segundo argumento.

Otro ejemplo: sort/2 . ¿Esto es ahora una relación o no?

8.4.3 sort / 2

8.4.3.1 Descripción

sort(List, Sorted) es verdadero iff Sorted unifica con la lista ordenada de List (7.1.6.5).

Entonces, de nuevo, sin relación. ¿Sorprendido? Mira 8.4.3.4 Ejemplos :

8.4.3.4 Ejemplos

...

sort([X, 1], [1, 1]). Succeeds, unifying X with 1. sort([1, 1], [1, 1]). Fails.

Si es necesario, se agrega una descripción de procedimiento separada, comenzando con "Procedurally,". De nuevo, no cubre ningún error en absoluto. Esta es una de las grandes ventajas de las descripciones estándar: los errores están separados de "hacer", lo que ayuda a un programador (= usuario del built-in) a detectar los errores de forma más sistemática. Para ser justos, aumenta ligeramente la carga del implementador que desea optimizar a mano y caso por caso. Tal código optimizado a menudo es propenso a errores sutiles de todos modos.

Plantilla xyz2 y modos

Aquí, se da una especificación completa de una o dos líneas de los modos y tipos de argumentos. La notación es muy similar a otras anotaciones que encuentra su origen en las declaraciones del modo DECsystem-10 1978.

8.5.2.2 Plantilla y modos

arg(+integer, +compound_term, ?term)

Sin embargo, existe una gran diferencia entre el enfoque de ISO y la pauta de Covington et al. Que es de naturaleza informal solamente y establece cómo un programador debe usar un predicado. El enfoque de ISO describe cómo se comportará el built-in, en particular qué errores se deben esperar. (Hay 4 errores siguientes desde arriba más un error adicional que no se puede ver desde arriba de la especificación, ver a continuación).

Errores xyz3

Se dan todas las condiciones de error, cada una en su propia subcláusula numerada alfabéticamente. El códice en 7.12 Errores :

Cuando se cumple más de una condición de error, el error que informa el procesador Prolog depende de la implementación.

Eso significa que cada condición de error debe indicar todas las condiciones previas donde se aplique. Todos ellos. Las condiciones de error no se leen como if-then-elsif-then ...

También significa que el codificador debe esforzarse más para encontrar buenas condiciones de error. Todo esto es una ventaja para el usuario-programador real, pero ciertamente un poco doloroso para el codificador y el implementador.

Muchas condiciones de error se derivan directamente de la especificación dada en xyz2 de acuerdo con las NOTAS en 8.1.3 Errores y de acuerdo con 7.12.2 Clasificación de errores ( resumen ). Para el predicado incorporado arg/3 , los errores a, b, c, d siguen de la especificación. Solo el error e no sigue.

8.5.2.3 Errores

a) N es una variable
- instantiation_error .

b) El Term es una variable
- instantiation_error .

c) N no es una variable ni un número entero
- type_error(integer, N) .

d) El Term no es una variable ni un término compuesto
- type_error(compound, Term) .

e) N es un número entero menor que cero
- domain_error(not_less_than_zero, N) .

xyz4 Ejemplos

(Opcional).

xyz5 predicados incorporados Bootstrapped

(Opcional). Define otros predicados que son muy similares, pueden ser "bootstrapped".

De acuerdo, sé que esta es una pregunta muy general y que se han escrito algunos artículos sobre el tema, pero tengo la sensación de que estas publicaciones cubren material muy básico y estoy buscando algo más avanzado que mejore el estilo y la eficiencia. Esto es lo que tengo en papel:

  • "Informe de investigación AI-1989-08 Efficient Prolog: A Practical Guide" de Michael A. Covington, 1989
  • "Programación eficiente de Prolog" por Timo Knuutila, 1992
  • "Directrices de codificación para Prolog" de Covington, Bagnara, O''Keefe, Wielemaker, Price, 2011

Temas de muestra cubiertos en estos: recursividad final y listas diferenciales, uso apropiado de indexación, uso apropiado de cortes, evitar afirmaciones y retractaciones, evitar CONSing, pautas de formato de código (sangrado, if-then-elses, etc.), convenciones de nomenclatura, documentación de código , orden de los argumentos, prueba.

¿Qué agregarías aquí de tu propia experiencia personal con Prolog? ¿Hay alguna guía de estilo especial aplicable solo a la programación de CLP? ¿Conoces algunos problemas de eficiencia comunes y sabes cómo manejarlos?

ACTUALIZAR:

Algunos puntos interesantes (pero aún demasiado básicos y muy generales para mí) se hacen aquí: pautas de programación de Prolog del equipo de Lifeware

Solo para resaltar todo el problema me gustaría citar "Pautas de codificación para Prolog" (Covington et al.):

Por lo que sabemos, nunca se ha publicado un conjunto coherente y razonablemente completo de pautas de codificación para Prolog. Además, cuando miramos el corpus de los programas Prolog publicados, no vemos surgir un estándar de facto. La razón más importante detrás de esta aparente omisión es que la pequeña comunidad de Prolog, debido a la falta de un estándar de lenguaje integral, está aún más fragmentada en subcomunidades centradas en sistemas Prolog individuales, ninguno de los cuales tiene una posición dominante.