¿Qué pasa con LISP, en todo caso, hace que sea más fácil implementar sistemas macro?

Estoy aprendiendo Scheme del SICP y tengo la impresión de que gran parte de lo que hace a Scheme y, aún más, LISP especial es el sistema macro. Pero, dado que las macros se expanden en tiempo de compilación, ¿por qué la gente no crea sistemas de macros equivalentes para C / Python / Java / lo que sea? Por ejemplo, uno podría vincular el pythoncomando expand-macros | pythono lo que sea. El código aún sería portátil para las personas que no usan el sistema macro, uno simplemente expandiría las macros antes de publicar el código. Pero no sé nada de eso, excepto las plantillas en C ++ / Haskell, que creo que no son lo mismo. ¿Qué pasa con LISP, en todo caso, hace que sea más fácil implementar sistemas macro?

Muchos Lispers le dirán que lo que hace a Lisp especial es la homoiconicidad , lo que significa que la sintaxis del código se representa utilizando las mismas estructuras de datos que otros datos. Por ejemplo, aquí hay una función simple (usando la sintaxis de Scheme) para calcular la hipotenusa de un triángulo rectángulo con las longitudes laterales dadas:

(define (hypot x y)
  (sqrt (+ (square x) (square y))))

Ahora, la homoiconicidad dice que el código anterior es realmente representable como una estructura de datos (específicamente, listas de listas) en el código Lisp. Por lo tanto, considere las siguientes listas y vea cómo se "pegan":

1. (define #2# #3#)
2. (hypot x y)
3. (sqrt #4#)
4. (+ #5# #6#)
5. (square x)
6. (square y)

Las macros le permiten tratar el código fuente como eso: listas de cosas. Cada uno de esos 6 "sublistas" contener punteros a otras listas, o a los símbolos (en este ejemplo: define, hypot, x, y, sqrt, +, square).

Entonces, ¿cómo podemos usar la homoiconicidad para "separar" la sintaxis y crear macros? Aquí hay un ejemplo simple. Vuelva a implementar la letmacro, que llamaremos my-let. Como recordatorio,

(my-let ((foo 1)
         (bar 2))
  (+ foo bar))

debería expandirse a

((lambda (foo bar)
   (+ foo bar))
 1 2)

Aquí hay una implementación que usa macros de "cambio de nombre explícito" del esquema ^† :

(define-syntax my-let
  (er-macro-transformer
    (lambda (form rename compare)
      (define bindings (cadr form))
      (define body (cddr form))
      `((,(rename 'lambda) ,(map car bindings)
          ,@body)
        ,@(map cadr bindings)))))

El formparámetro está vinculado a la forma real, por lo que para nuestro ejemplo, sería (my-let ((foo 1) (bar 2)) (+ foo bar)). Entonces, analicemos el ejemplo:

1. Primero, recuperamos los enlaces del formulario. cadragarra la ((foo 1) (bar 2))parte del formulario.

2. Luego, recuperamos el cuerpo de la forma. cddragarra la ((+ foo bar))parte del formulario. (Tenga en cuenta que esto pretende capturar todas las subformas después del enlace; por lo tanto, si el formulario fuera

   (my-let ((foo 1)
            (bar 2))
     (debug foo)
     (debug bar)
     (+ foo bar))
   

   entonces el cuerpo sería ((debug foo) (debug bar) (+ foo bar)).)

3. Ahora, en realidad construimos la resultante lambda expresión y llamamos usando los enlaces y el cuerpo que hemos recopilado. El backtick se llama "cuasiquote", lo que significa tratar todo dentro de la cuasiquote como datos literales, excepto los bits después de las comas ("entre comillas").
   • Los (rename 'lambda)medios para usar el lambdaenlace en vigor cuando se define esta macro , en lugar de cualquier lambdaenlace que pueda existir cuando se usa esta macro . (Esto se conoce como higiene ).
   • (map car bindings) devoluciones (foo bar) : el primer dato en cada uno de los enlaces.
   • (map cadr bindings) devoluciones (1 2) : el segundo dato en cada uno de los enlaces.
   • ,@ hace "empalme", ​​que se usa para expresiones que devuelven una lista: hace que los elementos de la lista se peguen en el resultado, en lugar de la lista misma.
4. Al juntar todo eso, obtenemos, como resultado, la lista (($lambda (foo bar) (+ foo bar)) 1 2), donde $lambdaaquí se refiere al cambio de nombre lambda.

Directo, ¿verdad? ;-) (Si no es sencillo para usted, imagine lo difícil que sería implementar un sistema macro para otros idiomas).

Por lo tanto, puede tener sistemas macro para otros idiomas, si tiene una manera de poder "separar" el código fuente de una manera no complicada. Hay algunos intentos de esto. Por ejemplo, sweet.js hace esto para JavaScript.

† Para los Schemers experimentados que leen esto, elegí intencionalmente usar macros de cambio de nombre explícito como un compromiso medio entre los defmacros utilizados por otros dialectos de Lisp y syntax-rules(que sería la forma estándar de implementar tal macro en Scheme). No quiero escribir en otros dialectos de Lisp, pero no quiero alienar a los no Schemers que no están acostumbrados syntax-rules.

Como referencia, aquí está la my-letmacro que usa syntax-rules:

(define-syntax my-let
  (syntax-rules ()
    ((my-let ((id val) ...)
       body ...)
     ((lambda (id ...)
        body ...)
      val ...))))

La syntax-caseversión correspondiente se ve muy similar:

(define-syntax my-let
  (lambda (stx)
    (syntax-case stx ()
      ((_ ((id val) ...)
         body ...)
       #'((lambda (id ...)
            body ...)
          val ...)))))

La diferencia entre los dos es que todo lo que en syntax-rulestiene una implícita #'aplicada, por lo que puede solamente tener pares de patrón / plantilla en syntax-rules, por lo tanto, es totalmente declarativa. En contraste, en syntax-case, el bit después del patrón es un código real que, al final, tiene que devolver un objeto de sintaxis ( #'(...)), pero también puede contener otro código.

Una opinión disidente: la homoiconicidad de Lisp es mucho menos útil de lo que la mayoría de los fanáticos de Lisp te hacen creer.

Para comprender las macros sintácticas, es importante comprender los compiladores. El trabajo de un compilador es convertir el código legible por humanos en código ejecutable. Desde una perspectiva de muy alto nivel, esto tiene dos fases generales: análisis y generación de código .

El análisis es el proceso de leer el código, interpretarlo de acuerdo con un conjunto de reglas formales y transformarlo en una estructura de árbol, generalmente conocida como AST (Árbol de sintaxis abstracta). Para toda la diversidad entre los lenguajes de programación, esta es una característica común notable: esencialmente cada lenguaje de programación de propósito general se analiza en una estructura de árbol.

Codigo de GENERACION toma el AST del analizador como su entrada y lo transforma en código ejecutable mediante la aplicación de reglas formales. Desde una perspectiva de rendimiento, esta es una tarea mucho más simple; muchos compiladores de idiomas de alto nivel dedican el 75% o más de su tiempo al análisis.

Lo que hay que recordar sobre Lisp es que es muy, muy viejo. Entre los lenguajes de programación, solo FORTRAN es más antiguo que Lisp. En el pasado, el análisis (la parte lenta de la compilación) se consideraba un arte oscuro y misterioso. Los documentos originales de John McCarthy sobre la teoría de Lisp (cuando era solo una idea de que nunca pensó que podría implementarse como un lenguaje de programación real) describe una sintaxis algo más compleja y expresiva que las modernas "expresiones S en todas partes para todo". "notación. Eso ocurrió más tarde, cuando la gente intentaba implementarlo. Debido a que el análisis no se entendía bien en ese entonces, básicamente lo golpearon y redujeron la sintaxis a una estructura de árbol homoicónica para hacer que el trabajo del analizador sea completamente trivial. El resultado final es que usted (el desarrollador) tiene que hacer mucho del analizador ' s trabaje para ello escribiendo el AST formal directamente en su código. ¡La homoiconicidad no "hace que las macros sean mucho más fáciles", sino que hace que escribir todo lo demás sea mucho más difícil!

El problema con esto es que, especialmente con la escritura dinámica, es muy difícil para las expresiones S transportar mucha información semántica. Cuando toda su sintaxis es del mismo tipo de cosas (listas de listas), no hay mucho en el contexto proporcionado por la sintaxis, por lo que el sistema macro tiene muy poco con qué trabajar.

La teoría del compilador ha recorrido un largo camino desde la década de 1960, cuando se inventó Lisp, y aunque las cosas que logró fueron impresionantes para su época, ahora parecen bastante primitivas. Para ver un ejemplo de un sistema moderno de metaprogramación, eche un vistazo al lenguaje Boo (tristemente subestimado). Boo es de tipo estático, orientado a objetos y de código abierto, por lo que cada nodo AST tiene un tipo con una estructura bien definida en la que un desarrollador de macros puede leer el código. El lenguaje tiene una sintaxis relativamente simple inspirada en Python, con varias palabras clave que dan un significado semántico intrínseco a las estructuras de árbol construidas a partir de ellas, y su metaprogramación tiene una sintaxis de cuasiquote intuitiva para simplificar la creación de nuevos nodos AST.

Aquí hay una macro que creé ayer cuando me di cuenta de que estaba aplicando el mismo patrón a un montón de lugares diferentes en el código GUI, donde llamaría BeginUpdate()a un control UI, realizaría una actualización en un trybloque y luego llamaría EndUpdate():

macro UIUpdate(value as Expression):
    return [|
        $value.BeginUpdate()
        try:
            $(UIUpdate.Body)
        ensure:
            $value.EndUpdate()
    |]

El macrocomando es, de hecho, una macro en sí , una que toma un cuerpo de macro como entrada y genera una clase para procesar la macro. Utiliza el nombre de la macro como una variable que representa el MacroStatementnodo AST que representa la invocación de la macro. El [| ... |] es un bloque de cuasiquote, que genera el AST que corresponde al código dentro y dentro del bloque de cuasiquote, el símbolo $ proporciona la función "sin comillas", sustituyendo en un nodo como se especifica.

Con esto, es posible escribir:

UIUpdate myComboBox:
   LoadDataInto(myComboBox)
   myComboBox.SelectedIndex = 0

y que se expanda a:

myComboBox.BeginUpdate()
try:
   LoadDataInto(myComboBox)
   myComboBox.SelectedIndex = 0
ensure:
   myComboBox.EndUpdate()

Expresando la macro de esta manera es más sencillo y más intuitivo de lo que sería en una macro Lisp, porque el desarrollador conoce la estructura de MacroStatementy sabe cómo el Argumentsy Bodypropiedades de trabajo, y que el conocimiento inherente puede ser utilizado para expresar los conceptos involucrados en una muy intuitiva camino. También es más seguro, porque el compilador conoce la estructura de MacroStatement, y si intentas codificar algo que no es válido para un MacroStatement, el compilador lo detectará de inmediato e informará el error en lugar de que no lo sepas hasta que algo explote en ti. tiempo de ejecución

Injertar macros en Haskell, Python, Java, Scala, etc. no es difícil porque estos lenguajes no son homicónicos; es difícil porque los idiomas no están diseñados para ellos, y funciona mejor cuando la jerarquía AST de su idioma está diseñada desde cero para ser examinada y manipulada por un sistema macro. Cuando trabajas con un lenguaje que fue diseñado teniendo en cuenta la metaprogramación desde el principio, ¡las macros son mucho más simples y fáciles de usar!

Estoy aprendiendo Scheme del SICP y tengo la impresión de que gran parte de lo que hace a Scheme y, aún más, LISP especial es el sistema macro.

¿Cómo es eso? Todo el código en SICP está escrito en estilo libre de macro. No hay macros en SICP. Solo en una nota al pie de la página 373 se mencionan las macros.

Pero, dado que las macros se expanden en tiempo de compilación

No son necesariamente Lisp proporciona macros tanto en intérpretes como en compiladores. Por lo tanto, puede que no haya un tiempo de compilación. Si tiene un intérprete Lisp, las macros se expanden en el momento de la ejecución. Dado que muchos sistemas Lisp tienen un compilador incorporado, uno puede generar código y compilarlo en tiempo de ejecución.

Probemos eso usando SBCL, una implementación de Common Lisp.

Cambiemos SBCL al intérprete:

* (setf sb-ext:*evaluator-mode* :interpret)

:INTERPRET

Ahora definimos una macro. La macro imprime algo cuando se solicita un código expandido. El código generado no se imprime.

* (defmacro my-and (a b)
    (print "macro my-and used")
    `(if ,a
         (if ,b t nil)
         nil))

Ahora usemos la macro:

MY-AND
* (defun foo (a b) (my-and a b))

FOO

Ver. En el caso anterior, Lisp no hace nada. La macro no se expande en el momento de la definición.

* (foo t nil)

"macro my-and used"
NIL

Pero en tiempo de ejecución, cuando se usa el código, la macro se expande.

* (foo t t)

"macro my-and used"
T

Nuevamente, en tiempo de ejecución, cuando se usa el código, la macro se expande.

Tenga en cuenta que SBCL se expandiría solo una vez al usar un compilador. Pero varias implementaciones de Lisp también proporcionan intérpretes, como SBCL.

¿Por qué las macros son fáciles en Lisp? Bueno, no son realmente fáciles. Solo en Lisps, y hay muchos, que tienen soporte de macro incorporado. Dado que muchos Lisps vienen con una amplia maquinaria para macros, parece que es fácil. Pero los mecanismos macro pueden ser extremadamente complicados.

La homoiconicidad hace que sea mucho más fácil implementar macros. La idea de que el código es datos y los datos son códigos hace posible que más o menos (salvo la captura accidental de identificadores, resueltos por macros higiénicos ) sustituyan libremente uno por el otro. Lisp y Scheme lo hacen más fácil con su sintaxis de expresiones S que están estructuradas de manera uniforme y, por lo tanto, fáciles de convertir en AST que forman la base de las macros sintácticas .

Los lenguajes sin S-Expressions o Homoiconicity se encontrarán con problemas para implementar Syntactic Macros, aunque todavía se puede hacer. El Proyecto Kepler está intentando presentarles Scala, por ejemplo.

El mayor problema con el uso de macros de sintaxis, aparte de la no homoiconicidad, es el problema de la sintaxis generada arbitrariamente. Ofrecen una gran flexibilidad y potencia, pero al precio de que su código fuente ya no sea tan fácil de entender o mantener.