Significado de los indicadores del modo instanciación en argumentos de predicados Prolog

En cuanto a la documentación de Prolog, las firmas de predicados a veces se escriben de la siguiente manera:

foo(:Bar, +Baz, -Qux, ?Mop) 

¿Qué son : + , - y ? para y cómo los interpreto? Además, ¿son estos los únicos que existen o hay más de ellos?

    Esos operadores de prefijos, en este contexto, representan modos de instanciación, es decir, te dicen qué argumentos deben ser variables o instanciadas cuando se llama al predicado. También le dicen si un argumento será (posiblemente más) instanciado por la llamada. También se pueden usar para decirle que el predicado al que está llamando metainterpretará de algún modo un argumento. Algunos de estos modos de instanciación son estándar, otros dependen del sistema. Los más usuales son:

    - – el argumento debe estar sin consolidar (probable argumento de salida)

    + – el argumento debe estar vinculado (argumento de entrada)

    ? – el argumento puede ser consolidado o no vinculado

    @ – el argumento no será más instanciado por la llamada

    : – el argumento será metainterpretado de alguna manera (a menudo ambiguo)

    0 – el argumento será interpretado como objective y llamado como tal

    N – donde N es un número natural; el argumento se interpretará como un cierre que se compondrá con N argumentos adicionales para construir un objective que se llamará

    Los diferentes sistemas proporcionan modos de instanciación diferentes o diferentes. Por ejemplo, para indicar que un argumento debe fundamentarse cuando se llama a un predicado, o para establecer que un argumento debe ser un indicador de predicado o que se interpretará como un cuerpo de regla gtwigtical. Tendrá que consultar la documentación del sistema Prolog que está utilizando para obtener más información.

    Las declaraciones de modo aparecieron por primera vez en el comstackdor DECsystem-10 a finales de los años setenta. La guía del usuario DECsystem-10 de 1978-09 es una de las primeras descripciones. La motivación se da 1982-11-10:

    Dicha información permite al comstackdor generar código más compacto, haciendo un mejor uso del almacenamiento en tiempo de ejecución. El ahorro de almacenamiento en tiempo de ejecución en particular a menudo puede ser muy sustancial. Las declaraciones de modo también ayudan a otras personas a entender cómo funciona su progtwig.

    DECsystem-10

    + – el argumento siempre será un NO-variable

    - – el argumento siempre será una variable

    ? – Sin restricción

    Tenga en cuenta que estas declaraciones se aplican a cada objective . En particular, se aplican a objectives recursivos. De esta manera, la siguiente statement de modo más su definición implica que el segundo argumento no es una lista parcial. Por lo tanto, un member(A, [c|_]) objective member(A, [c|_]) no estaría conforme. De modo que la interfaz y la implementación son algo interdependientes, lo que puede conducir a casos bastante complejos, cuando deben tenerse en cuenta las unificaciones realizadas por el predicado mismo.

     :- mode member(?, +). member(X, [X|_]). % member(X, [X,.._]) in DEC10 member(X, [_|L]) :- member(X, L). 

    En caso de que una statement de modo sea violada por un objective concreto, la statement será ignorada o producirá un error que en ese momento significaba escribir un mensaje de error y fallar. El intérprete de DECsystem-10 siempre ignoró las declaraciones.

    En el fondo, en la década de 1970, la guía de usuario DEC 10 dio lugar a dos interpretaciones de declaraciones de modo: la primera es la prescriptiva que produce errores en caso de que los modos no se cumplan por un llamador. El segundo es completamente informal, ignorando las declaraciones de modo en tiempo de ejecución. El primero se usa dentro del estándar Prolog, este último se encuentra en la documentación de algunos sistemas Prolog.

    ISO / IEC-Prolog: subcláusula de plantilla y modos

    El estándar Prolog (ISO / IEC 13211-1: 1995, 2007, 2012) utiliza el siguiente formato para la definición de predicados incorporados. Comienza con la subcláusula .1 Descripción, .2 Plantilla y modos, .3 Errores y, opcionalmente, continúa con .4 Ejemplos, .5 Privilegios incorporados Bootstrapped.

    8.1.2 Plantilla y modos

    Una especificación para el tipo de argumentos y que
    de ellos se creará una instancia para el predicado incorporado a
    estar satisfecho. Los casos forman un conjunto mutuamente exclusivo.

    Los modos concretos son:

    + – el argumento se instanciará.

    @ – como + y el argumento permanecerá inalterado.

    - – el argumento será una variable que se instanciará si la meta tiene éxito.

    ? – sin requisito de modo, el argumento puede ser una variable o una instancia.

    Si se invocó un predicado con un modo diferente, se produce un instantiation_error o uninstantiation_error . Si el tipo no coincide, se produce un type_error . De esta manera, el progtwigdor puede anticipar muchos errores simplemente mirando la plantilla y subcláusula de modo sin leer las condiciones de error detalladas.

    Otros sistemas

    Los sistemas que difieren de ISO también difieren entre sí en su interpretación precisa de modos. Muchos realizan una falla silenciosa en caso de que un error de tipo sea apropiado. Consideran las declaraciones de modo como un medio para indicar casos en los que se espera que el predicado funcione de otra manera con un significado indefinido. A menudo, el - se interpreta aproximadamente de la siguiente manera. Como no hay una referencia real que defina el significado, esto es lo que reuní informalmente:

    - – el argumento es un “argumento de salida”. Lo que significa que se unificará con el término resultante después de que se haya ejecutado el objective. Entonces la discusión es firme. A menudo, ningún error está asociado con tal argumento.