macro higiénico

En los lenguajes de programación que tienen sistemas de macros no higiénicos, es posible que las asignaciones de variables existentes queden ocultas a una macro por asignaciones de variables que se crean durante su expansión. En C , este problema se puede ilustrar con el siguiente fragmento:

#define INCI(i) { int a=0; ++i; } int main ( void ) { int a = 4 , b = 8 ; INCI ( a ); INCI ( b ); printf ( "a ahora es %d, b ahora es %d \n " , a , b ); return 0 ; }

Al ejecutar lo anterior a través del preprocesador de C se obtiene:

int main ( void ) { int a = 4 , b = 8 ; { int a = 0 ; ++ a ; }; { int a = 0 ; ++ b ; }; printf ( "a ahora es %d, b ahora es %d \n " , a , b ); return 0 ; }

La variable adeclarada en el ámbito superior queda oculta por la avariable en la macro, que introduce un nuevo ámbito . Como resultado, anunca se modifica durante la ejecución del programa, como muestra la salida del programa compilado:

a ahora es 4, b ahora es 9

El problema de la higiene puede ir más allá de las vinculaciones de variables. Considere esta macro de Common Lisp :

( defmacro my-unless ( condición &cuerpo cuerpo ) ` ( si ( no , condición ) ( progn ,@ cuerpo )))

Aunque esta macro no hace referencia a variables, asume que los símbolos "if", "not" y "progn" están vinculados a sus definiciones habituales en la biblioteca estándar. Sin embargo, si la macro anterior se utiliza en el siguiente código:

( flet (( no ( x ) x )) ( mi-a menos que t ( formato t "¡Esto no debe imprimirse!" )))

La definición de "no" se ha modificado localmente y, por lo tanto, también la expansión de my-unlesslos cambios.

Sin embargo, cabe señalar que este comportamiento está prohibido en Common Lisp, según lo estipulado en la sección 11.1.2.1.2, Restricciones del paquete COMMON-LISP para programas conformes . Aun así, es posible redefinir completamente las funciones. Algunas implementaciones de Common Lisp proporcionan bloqueos de paquete para evitar que el usuario modifique definiciones en los paquetes por error.

Por supuesto, el problema puede ocurrir de manera similar con las funciones definidas por el programa:

( defun operador-definido-por-usuario ( cond ) ( no cond ))( defmacro my-unless ( condición &body body ) ` ( if ( operador-definido-por-usuario , condición ) ( progn ,@ body ))); ... más tarde ...( flet (( operador-definido-por-usuario ( x ) x )) ( my-unless t ( formato t "¡Esto no debería imprimirse!" )))

El sitio de uso redefine user-defined-operatory, por lo tanto, cambia el comportamiento de la macro.

La solución más sencilla, si se necesita almacenamiento temporal durante la expansión de una macro, es usar nombres de variables poco comunes en la macro con la esperanza de que el resto del programa nunca utilice esos mismos nombres.

#define INCI(i) { int INCIa = 0; ++i; } int main ( void ) { int a = 4 , b = 8 ; INCI ( a ); INCI ( b ); printf ( "a ahora es %d, b ahora es %d \n " , a , b ); return 0 ; }

INCIaHasta que se cree una variable con ese nombre , esta solución produce el resultado correcto:

a ahora es 5, b ahora es 9

El problema se resuelve para el programa actual, pero esta solución no es robusta. El programador debe mantener sincronizadas las variables utilizadas dentro de la macro y las del resto del programa. En concreto, el uso de la macro INCIen una variable INCIafallará del mismo modo que la macro original falló en una variable a.

En algunos lenguajes de programación, es posible generar un nuevo nombre de variable o símbolo y vincularlo a una ubicación temporal. El sistema de procesamiento del lenguaje garantiza que esto nunca entre en conflicto con otro nombre o ubicación en el entorno de ejecución. La responsabilidad de elegir usar esta característica dentro del cuerpo de una definición de macro recae en el programador. Este método se usó en MacLisp , donde una función llamada gensympodía usarse para generar un nuevo nombre de símbolo. gensymExisten funciones similares (generalmente también llamadas) en muchos lenguajes tipo Lisp, incluido el estándar Common Lisp ampliamente implementado ^{[ 4 ]} y Elisp .

Aunque la creación de símbolos resuelve el problema de la ocultación de variables, no resuelve directamente el problema de la redefinición de funciones. ^{[ 5 ]} Sin embargo, gensymlas funcionalidades de macros y las funciones de la biblioteca estándar son suficientes para incorporar macros higiénicas en un lenguaje no higiénico. ^{[ 6 ]}

Esto es similar a la ofuscación en el sentido de que un solo nombre es compartido por múltiples expansiones de la misma macro. Sin embargo, a diferencia de un nombre inusual, se utiliza un símbolo no interno en tiempo de lectura (denotado por la #:notación), para el cual es imposible que ocurra fuera de la macro, similar a gensym.

Utilizando paquetes como en Common Lisp, la macro simplemente usa un símbolo privado del paquete en el que se define. El símbolo no aparecerá accidentalmente en el código del usuario. El código del usuario tendría que acceder al interior del paquete usando la ::notación de doble punto ( ) para darse permiso para usar el símbolo privado, por ejemplo cool-macros::secret-sym. En ese punto, el problema de la falta accidental de higiene es irrelevante. Además, el estándar ANSI Common Lisp clasifica la redefinición de funciones y operadores estándar, global o localmente, como invocación de comportamiento indefinido . Dicho uso puede ser diagnosticado por la implementación como erróneo. Por lo tanto, el sistema de paquetes de Lisp proporciona una solución viable y completa al problema de la higiene de macros, que puede considerarse un caso de conflicto de nombres.

Por ejemplo, en el ejemplo de redefinición de función definida por el programa , la my-unlessmacro puede residir en su propio paquete, donde user-defined-operatores un símbolo privado en ese paquete. El símbolo user-defined-operatorque aparece en el código del usuario será entonces un símbolo diferente, sin relación con el utilizado en la definición de la my-unlessmacro.

En algunos lenguajes, la expansión de una macro no tiene por qué corresponder a código textual; en lugar de expandirse a una expresión que contenga el símbolo f, una macro puede producir una expansión que contenga el objeto real al que se refiere f. Del mismo modo, si la macro necesita usar variables locales u objetos definidos en su paquete, puede expandirse a una invocación de un objeto de cierre cuyo entorno léxico sea el de la definición de la macro.

Syntax-rules es una herramienta de coincidencia de patrones de alto nivel que intenta simplificar la escritura de macros. Sin embargo, syntax-rulesno puede describir de forma concisa ciertas clases de macros y resulta insuficiente para expresar otros sistemas de macros. Syntax-rules se describió en un apéndice del documento R4RS, pero no era obligatorio. Posteriormente, R5RS lo adoptó como una herramienta estándar para macros. A continuación, se muestra un ejemplo syntax-rulesde macro que intercambia el valor de dos variables:

( define-syntax swap! ( syntax-rules () (( _ a b ) ( let (( temp a )) ( set! a b ) ( set! b temp )))))

Debido a las deficiencias de un syntax-rulessistema de macros puramente basado en, el estándar Scheme R6RS adoptó el sistema de macros sintáctica-case. ^{[ 10 ]} A diferencia de syntax-rules, syntax-casecontiene tanto un lenguaje de coincidencia de patrones como una funcionalidad de bajo nivel para escribir macros. El primero permite escribir macros de forma declarativa, mientras que el segundo permite la implementación de interfaces alternativas para escribir macros. El ejemplo de intercambio anterior es casi idéntico en syntax-caseporque el lenguaje de coincidencia de patrones es similar:

( define-syntax swap! ( lambda ( stx ) ( syntax-case stx () (( _ a b ) ( syntax ( let (( temp a )) ( set! a b ) ( set! b temp )))))))

Sin embargo, syntax-casees más potente que las reglas de sintaxis. Por ejemplo, syntax-caselas macros pueden especificar condiciones secundarias en sus reglas de coincidencia de patrones mediante funciones Scheme arbitrarias. Alternativamente, quien escribe la macro puede optar por no usar la interfaz de coincidencia de patrones y manipular la sintaxis directamente. Al usar la datum->syntaxfunción, las macros de sintaxis también pueden capturar identificadores intencionadamente, rompiendo así la higiene.

También se han propuesto e implementado otros sistemas de macros para Scheme. Los cierres sintácticos y el renombramiento explícito ^{[ 11 ]} son ​​dos sistemas de macros alternativos. Ambos sistemas son de nivel inferior a `syntax-rules` y dejan la aplicación de la higiene al escritor de macros. Esto difiere tanto de `syntax-rules` como de `syntax-case`, que aplican la higiene automáticamente por defecto. Los ejemplos de intercambio anteriores se muestran aquí utilizando una implementación de cierre sintáctico y renombramiento explícito, respectivamente:

;; cierres sintácticos ( define-syntax swap! ( sc-macro-transformer ( lambda ( form environment ) ( let (( a ( close-syntax ( cadr form ) environment )) ( b ( close-syntax ( caddr form ) environment ))) ` ( let (( temp , a )) ( set! , a , b ) ( set! , b temp )))))));; renombramiento explícito ( ¡ definir intercambio de sintaxis! ( er-macro-transformer ( lambda ( forma renombrar comparar ) ( let (( a ( forma cadr )) ( b ( forma caddr )) ( temp ( renombrar 'temp ))) ` ( , ( renombrar 'let ) (( , temp , a )) ( , ( renombrar 'set! ) , a , b ) ( , ( renombrar 'set! ) , b , temp )))))))

• Esquema : reglas de sintaxis, casos sintácticos, cierres sintácticos y otros.
• Racket , una variante de Scheme, cuyo sistema de macros se basaba originalmente en la sintaxis de mayúsculas y minúsculas, ahora cuenta con más funciones.
• Nemerle ^{[ 12 ]}
• Dylan
• Elixir ^{[ 13 ]}
• Nim
• Óxido
• Haxe
• Mary2 – Cuerpos macro con ámbito definido en un lenguaje derivado de ALGOL 68, alrededor de 1978.
• Julia ^{[ 14 ]}
• Raku – admite macros higiénicas y no higiénicas ^{[ 15 ]}
• Lean ^{[ 16 ]}