¿Cuándo debo usar macro en mi programa o no?

Esta pregunta está inspirada en una respuesta informativa de @tarsius. Creo que muchos tienen grandes experiencias para compartir otros. Espero que esta pregunta se convierta en una de las Grandes preguntas subjetivas y ayude a los programadores de Emacs.

Regla de oro

Use macros para la sintaxis , pero nunca para la semántica.

Está bien usar una macro para un poco de azúcar sintáctica, pero es una mala idea poner la lógica en un cuerpo de macro independientemente de si está en la macro en sí o en la expansión. Si siente la necesidad de hacer eso, escriba una función y una "macro compañera" para el azúcar sintáctico. Simplemente hablando, si tienes un letmacro en tu macro estás buscando problemas.

¿Por qué?

Las macros tienen muchos inconvenientes:

• Se expanden en el momento de la compilación y, por lo tanto, deben escribirse cuidadosamente para mantener la compatibilidad binaria en varias versiones. Por ejemplo, eliminar una función o variable utilizada en la expansión de una macro romperá el código de bytes de todos los paquetes dependientes que estaban usando esta macro. En otras palabras, si cambia la implementación de una macro de una manera incompatible, todos los paquetes dependientes deben volver a compilarse. Y la compatibilidad binaria no siempre es obvia ...
• Debe tener cuidado de mantener un orden de evaluación intuitivo . Es muy fácil escribir una macro que evalúe un formulario con demasiada frecuencia, o en el momento equivocado, o en el lugar equivocado, etc.
• Debe tener en cuenta la semántica de enlace : las macros heredan su contexto de enlace del sitio de expansión , lo que significa que no sabe a priori qué variables léxicas existen y si el enlace léxico está disponible. Una macro debe funcionar con ambas semánticas vinculantes.
• En relación con esto, debe tener cuidado al escribir macros que crean cierres . Recuerde, obtiene los enlaces desde el sitio de expansión, no desde la definición léxica, así que esté atento a lo que cierra y cómo crea el cierre (recuerde, no sabe si el enlace léxico está activo en el sitio de expansión y si incluso tienes cierres disponibles).

Desde mi experiencia leyendo, depurando y modificando mi código Elisp y el de otros, sugiero evitar las macros tanto como sea posible.

Lo obvio acerca de las macros es que no evalúan sus argumentos. Lo que significa que si tiene una expresión compleja envuelta en una macro, no tiene idea de si se evaluará o no, y en qué contexto, a menos que busque la definición de macro. Esto podría no ser un gran problema para usted, ya que conoce la definición de su propia macro (actualmente, probablemente no unos años más tarde).

Esta desventaja no se aplica a las funciones: todos los argumentos se evalúan antes de la llamada a la función. Lo que significa que puede desarrollar la complejidad de evaluación en una situación de depuración desconocida. Incluso puede omitir directamente las definiciones de las funciones desconocidas para usted, siempre que devuelvan datos directos y asuma que no tocan el estado global.

Para reformularlo de otra manera, las macros se convierten en parte del lenguaje. Si está leyendo un código con macros desconocidas, casi está leyendo un código en un idioma que no conoce.

Excepciones a las reservas anteriores:

Las macros estándar como push, pop, dolisthacen realmente mucho para usted, y se sabe que otros programadores. Básicamente son parte de la especificación del lenguaje. Pero es prácticamente imposible estandarizar su propia macro. No solo es difícil encontrar algo simple y útil como los ejemplos anteriores, sino que es aún más difícil convencer a cada programador para que lo aprenda.

Además, no me importan las macros como save-selected-window: almacenan y restauran el estado y evalúan sus argumentos de la misma manera progn. Bastante sencillo, en realidad simplifica el código.

Otro ejemplo de macros OK puede ser cosas como defhydrao use-package. Estas macros básicamente vienen con su propio mini idioma. Y todavía tratan datos simples o actúan como progn. Además, generalmente están en el nivel superior, por lo que no hay variables en la pila de llamadas de las que dependan los argumentos macro, lo que lo hace un poco más simple.

Un ejemplo de una mala macro, en mi opinión, es magit-section-actiony magit-section-caseen Magit. El primero ya fue eliminado, pero el segundo aún permanece.

Seré directo: no entiendo qué significa "usar para sintaxis, no para semántica". Es por eso que parte de esta respuesta tratará con la respuesta de lunaryon , y la otra parte será mi intento de responder la pregunta original.

Cuando la palabra "semántica" utilizada en la programación, se refiere a la forma en que el autor del idioma eligió interpretar su idioma. Esto generalmente se reduce a un conjunto de fórmulas que transforman las reglas gramaticales del lenguaje en otras reglas con las que se supone que el lector está familiarizado. Por ejemplo, Plotkin en su libro Structural Approach to Operational Semantics usa un lenguaje de derivación lógica para explicar a qué se evalúa la sintaxis abstracta (qué significa ejecutar un programa). En otras palabras, si la sintaxis es lo que constituye el lenguaje de programación en algún nivel, entonces tiene que tener alguna semántica, de lo contrario es, bueno ... no un lenguaje de programación.

Pero, olvidemos por el momento las definiciones formales, después de todo, es importante entender la intención. Entonces, parece que lunaryon alentaría a sus lectores a usar macros cuando no se agregue un nuevo significado al programa, sino solo una especie de abreviatura. Para mí, esto suena extraño y en marcado contraste con cómo se usan realmente las macros. A continuación hay ejemplos que claramente crean nuevos significados:

1. defun y amigos, que son una parte esencial del lenguaje, no pueden describirse en los mismos términos que describiría las llamadas a funciones.

2. setflas reglas que describen cómo funcionan las funciones son inadecuadas para describir los efectos de una expresión como (setf (aref x y) z).

3. with-output-to-stringTambién cambia la semántica del código dentro de la macro. Del mismo modo, with-current-buffery un montón de otras with-macros.

4. dotimes y similares no se pueden describir en términos de funciones.

5. ignore-errors cambia la semántica del código que envuelve.

6. Hay un montón de macros definidas en cl-libpackage, eieiopackage y algunas otras bibliotecas casi ubicuas utilizadas en Emacs Lisp que, aunque pueden parecer formas de función, tienen diferentes interpretaciones.

Entonces, en todo caso, las macros son la herramienta para introducir nuevas semánticas en un lenguaje. No puedo pensar en una forma alternativa de hacerlo (al menos no en Emacs Lisp).

Cuando no usaría macros:

1. Cuando no introducen ninguna construcción nueva, con nueva semántica (es decir, la función haría el trabajo igual de bien).

2. Cuando esto es solo una especie de conveniencia (es decir, crear una macro nombrada mvbque se expande cl-multiple-value-bindpara hacerla más corta).

3. Cuando espero que la macro oculte una gran cantidad de código de manejo de errores (como se ha señalado, las macros son difíciles de depurar).

Cuando preferiría las macros a las funciones:

1. Cuando los conceptos específicos del dominio están oscurecidos por las llamadas a funciones. Por ejemplo, si uno necesita pasar el mismo contextargumento a un grupo de funciones que deben llamarse sucesivamente, preferiría envolverlas en una macro, donde el contextargumento está oculto.

2. Cuando el código genérico en forma de función es demasiado detallado (las construcciones de iteración desnuda en Emacs Lisp son demasiado detalladas para mi gusto y exponen innecesariamente al programador a los detalles de implementación de bajo nivel).

Ilustración

A continuación se muestra la versión diluida destinada a dar una idea de lo que se entiende por semántica en informática.

Supongamos que tiene un lenguaje de programación extremadamente simple con solo estas reglas de sintaxis:

variable := 1 | 0
operation := +
expression := variable | (expression operation expression)

con este lenguaje podemos construir "programas" como (1+0)+1o 0o ((0+0))etc.

Pero mientras no hayamos proporcionado reglas semánticas, estos "programas" no tienen sentido.

Supongamos que ahora equipamos nuestro lenguaje con las reglas (semánticas):

0+0  0+1  1+0  1+1  (exp)
---, ---, ---, ---, -----
 0   1+0   1    0    exp

Ahora podemos calcular usando este lenguaje. Es decir, podemos tomar la representación sintáctica, entenderla de manera abstracta (en otras palabras, convertirla en sintaxis abstracta), luego usar reglas semánticas para manipular esta representación.

Cuando hablamos de la familia de lenguajes Lisp, las reglas semánticas básicas de evaluación de funciones son aproximadamente las del cálculo lambda:

(f x)  (lambda x y)   x
-----, ------------, ---
 fx        ^x.y       x

Los mecanismos de cotización y macroexpansión también se conocen como herramientas de metaprogramación, es decir, permiten hablar sobre el programa, en lugar de solo programar. Logran esto creando nuevas semánticas utilizando la "meta capa". El ejemplo de una macro tan simple es:

(a . b)
-------
(cons a b)

Esto no es realmente una macro en Emacs Lisp, pero podría haber sido. Elegí solo por simplicidad. Tenga en cuenta que ninguna de las reglas semánticas definidas anteriormente se aplicaría a este caso ya que el candidato más cercano (f x)interpreta fcomo una función, mientras aque no es necesariamente una función.