Unidad 6: Metaprogramación y orientación a objetos

Los lenguajes que usamos habitualmente para desarrollar (C, Java, Haskell, Python, Racket) son lenguajes de propósito general (GPL): aplicables a cualquier dominio, pero sin características especializadas para ninguno. En contraste, un lenguaje de dominio específico (DSL) está especializado en un dominio particular: SQL para bases de datos relacionales, Mathematica/Wolfram para cálculo simbólico, los lenguajes de shell para automatizar el sistema operativo, Emacs Lisp para configurar un editor.

Un DSL puede ofrecer una notación más conveniente (más cercana a la del dominio) y mejor desempeño (explotando características del dominio). ¿Por qué, entonces, programamos mayoritariamente en GPLs? Porque desplegar un DSL nuevo obliga a construir desde cero todo su ecosistema: compilador o intérprete, editor, depurador, detector de errores de sintaxis. Eso cuesta tiempo y dinero, y vuelve más riesgosa la propuesta.

Una alternativa para bajar ese costo es no reinventar la rueda: incrustar (o compilar) el DSL dentro de un lenguaje anfitrión existente, que ya trae todas esas herramientas. Una forma de lograrlo es mediante macros.

Muchos lenguajes ofrecen un preprocesador sintáctico que traduce términos antes de entregárselos al intérprete o compilador: macros en C o Scheme, templates en C++, genéricos en Java. Comparten una idea: permiten extender el lenguaje con nuevos constructos sin modificar internamente su implementación.

Recordemos cómo agregábamos un constructo en las unidades anteriores: extender la sintaxis concreta, extender el AST, extender parse y extender interp. Cada capa había que tocarla. Las macros ofrecen otro camino: el preprocesador "compila" el lenguaje extendido hacia el lenguaje original.

Ya vimos un caso puntual de esto: la expresión with no tenía un nodo propio en el AST; el parser la traducía a una aplicación de función anónima. Las macros generalizan esa idea de definir una nueva sintaxis y traducirla al núcleo del lenguaje.

Queremos un constructo my-time que mida cuántos milisegundos toma evaluar una expresión, apoyándonos en la primitiva current-milliseconds.

Una definición con defmac se parece mucho a una definición de función: hay un nombre, un patrón con metavariables y un cuerpo que es la expansión. La diferencia es lo que ocurre en tiempo de compilación:

El evaluador no sabe nada de las macros: solo conoce el lenguaje núcleo. Tenemos entonces dos etapas separadas: primero un tiempo de expansión que traduce el lenguaje-con-macros al lenguaje núcleo, y luego un tiempo de ejecución donde el evaluador corre el programa expandido. En DrRacket, el Macro Stepper permite observar paso a paso estas transformaciones.

En Racket, muchísimos constructos que damos por primitivos están en realidad implementados como macros, apiladas unas sobre otras. El sistema de macros no es un adorno: es la herramienta central con la que el lenguaje se refina a sí mismo.

Definamos let con un único par de asociación como macro:

La expansión es la aplicación de una función anónima, tal como hacía el parser con with. Pero el let real admite varios pares. Para eso necesitamos la elipsis …​, que en el patrón significa "cero o más ocurrencias del patrón anterior" y en la expansión repite el fragmento correspondiente. Observemos cómo id y e aparecen juntos en el patrón pero se expanden por separado:

Así, (my-let ([x 1] [y 2]) (+ x y)) se expande a lambda (x y) (+ x y 1 2). Una sola definición, muy parecida a la de una función, soporta una cantidad arbitraria de argumentos. La elipsis es el mecanismo que hace a las macros genuinamente más expresivas que las funciones a nivel sintáctico.

Las macros permiten introducir nuevas formas de escribir condicionales, porque pueden alterar el flujo de control normal. Queremos una sintaxis (check c then e1 else e2). Un primer intento sin restricciones:

El problema es que then y else son tratados como metavariables cualesquiera: (check1 (< 10 2) (/ 1 0) "hola" else "chao") se acepta sin chistar (y ni siquiera evalúa (/ 1 0), porque nunca aparece en la expansión). Queremos obligar a que ciertas palabras aparezcan literalmente. Para eso está #:keywords:

Ahora then y else no son metavariables: deben calzar literalmente. Usar la macro con otra palabra en su lugar produce el famoso error bad syntax, que significa "detecto que intentas usar una macro, pero la estás usando mal".

Como podemos modificar el flujo de control, podemos definir una disyunción binaria con lógica de cortocircuito: evaluar el segundo argumento solo si el primero es falso. Esto tampoco puede ser una función, porque la evaluación temprana forzaría ambos argumentos.

¿Por qué el let? Consideremos una variante ingenua:

Como la expansión es un copy-paste literal, e1 aparece dos veces en (if e1 e1 e2) y por lo tanto se evalúa dos veces. El let de my-or evita esto: evalúa e1 una sola vez, la liga a un identificador y reutiliza ese valor ya calculado.

Volvamos a my-or, cuya expansión usa internamente el nombre result. ¿Qué pasa si el contexto que invoca la macro también usa un identificador llamado result?

Intuitivamente el resultado correcto es #t (es una disyunción entre #f y #t). Pero si la expansión fuese una sustitución textual ingenua, obtendríamos:

El result interno de la macro opacaría al result externo del programador. Esto se llama captura inadvertida de identificadores: sin darse cuenta, el usuario "le achuntó" a un nombre usado dentro de la expansión y su programa cambió de significado. El contexto que invoca no tiene manera de saber ni de adivinar qué identificadores usa la macro por dentro.

Ningún lenguaje puede proveer de antemano todos los constructos que podrían ser útiles: ni siquiera especificaciones enormes, como las casi 700 páginas del lenguaje Java, logran anticiparlo todo. La respuesta del diseño de Scheme, citada en su Revised⁶ Report, es:

Es decir: un núcleo mínimo pero muy poderoso, pocas restricciones sobre qué puede aparecer dónde (valores verdaderamente de primera clase) y un sistema de macros potente para extender el lenguaje con nuevas primitivas de alto nivel. Las macros son fáciles de distribuir (son parte del lenguaje, no del compilador), por lo que las extensiones no fragmentan el ecosistema. Ilustremos este poder con dos DSLs: bucles guardados y autómatas finitos.

Queremos una primitiva my-while que reciba una condición y un cuerpo y los itere. No puede ser una función (la evaluación temprana evaluaría la condición una sola vez). La idea de implementación es desenvolver el cuerpo del bucle un paso a la vez:

Como segundo DSL, agreguemos una primitiva para decidir el lenguaje aceptado por un autómata finito determinista (con un único estado de aceptación). El siguiente autómata reconoce los accesores de listas de Lisp (car, cdr, cadr, caddr…​): toda cadena que empieza con c, termina con r, y entre medio tiene una o más a o d.

Un objeto es la encapsulación de estado y comportamiento:

Y un principio fundamental: la invocación de métodos se concibe como paso de mensajes. Le enviamos un mensaje a un objeto; si lo entiende, ejecuta el método asociado, cuyo resultado puede depender de su estado interno.

Notemos qué no aparece en esta definición: clases, herencia, tipos estáticos, ni ningún lenguaje en particular. Todo eso se construye encima de estas ideas. Vamos a codificar objetos en Racket usando clausuras, y el propósito es entender la semántica de la orientación a objetos desde cero.

Una clausura ya es, en germen, un objeto: encapsula estado (sus variables libres) y tiene un método (la aplicación). Con estado inmutable:

Con estado mutable, capturado por alcance estático:

Estos objetos son primitivos: tienen un solo método (la aplicación). El salto conceptual llega cuando queremos más de un método.

Lo único que podemos variar al invocar una función son sus argumentos. Aprovechemos entonces el primer argumento como un mensaje que selecciona el método. Un contador bidireccional:

Este es el patrón de dispatch: el objeto recibe un mensaje, hace un análisis de casos y ejecuta el código asociado. Para métodos con distinta cantidad de argumentos usamos la notación de punto (λ (cmd . args) …​), donde args es la lista de argumentos adicionales:

Observemos la estructura: primero el estado (vals) definido afuera, para que sobreviva entre invocaciones y sea capturado por alcance estático; luego los métodos, anidados después de los campos para poder acceder a ellos; finalmente el dispatcher. La encapsulación es consecuencia directa de usar clausuras: una vez creado el objeto, vals no es accesible desde ninguna parte salvo a través de los métodos.

Generalicemos. Todo objeto sigue esta forma: un let con los campos, una lista de asociación methods que empareja cada nombre de método con su clausura, y un dispatcher que busca el método con assoc y lo aplica con apply:

Pedirle al programador que escriba ese patrón para cada objeto garantizaría 0% de adopción. Lo mecanizamos con una macro OBJECT que expande al patrón, y una macro → para enviar mensajes:

field y method son palabras clave; las elipsis expanden todos los campos y todos los métodos. La macro → es azúcar: (→ o m arg …​) se traduce a (o 'm arg …​), ocultando que el objeto es una función y que el mensaje es un símbolo. Ahora los objetos se escriben de forma limpia:

Como los objetos son funciones (valores de primera clase), podemos usar funciones de orden superior como constructores (fábricas) de objetos, almacenarlos en estructuras, pasarlos como argumentos, etc. El ejemplo clásico es un árbol binario donde nodos y hojas responden ambos al mensaje sum con implementaciones distintas:

Que (→ …​ sum) invoque la suma recursiva de un nodo o el valor de una hoja según el objeto concreto en tiempo de ejecución es dispatch dinámico: la selección de la implementación de una operación polimórfica se hace en ejecución. Es una característica central para la flexibilidad de la orientación a objetos.

Con la macro anterior, enviar un mensaje desconocido produce un error de bajo nivel (cdr: contract violation …​) que expone la implementación: el objeto point no tiene ninguna lista, pero el error habla de una. Basta mejorar el dispatcher para dar un error al nivel de abstracción correcto (el resto de la macro no cambia):

Consideremos un método above sobre puntos, que recibe otro punto y retorna el que está más arriba en el eje Y:

Cuando el otro punto no es el más alto, queremos retornar el objeto que recibió el mensaje: self. Nuestros objetos todavía no pueden referirse a sí mismos. Necesitamos dotarlos de identidad.

El objeto es una función; queremos referirnos a esa función desde dentro de sí misma. Es exactamente el problema de una definición recursiva, que resolvemos con letrec:

El setter x! retorna self, lo que permite encadenar invocaciones. Esta es una definición estática de self: por alcance estático, self queda ligado de una vez y para siempre al objeto.

Al llevar esto a la macro, envolvemos el patrón en un letrec que liga self:

Pero al usarla, self resulta ser un identificador no ligado. La razón es la higiene: el self que escribe el programador en el cuerpo de un método y el self que introduce la macro son, tras la expansión, identificadores distintos. La higiene, que antes nos protegía, ahora nos estorba: aquí queremos que se capture self. La solución es romper la higiene selectiva y explícitamente con #:captures:

#:captures self le indica al sistema que no sea higiénico con self, de modo que el self escrito por el programador en los métodos calce con el self del letrec. Es el mismo patrón que con el alcance dinámico: mal comportamiento por defecto, pero valioso cuando se activa de forma deliberada.

Con self podemos retornarnos a nosotros mismos (como en x! arriba) y enviarnos mensajes a nosotros mismos. Un objeto con dos métodos mutuamente recursivos:

Sin self, un método no podría invocar a otro método del mismo objeto respetando el paso de mensajes. (Como las invocaciones a self están en posición de cola, además se benefician de la optimización de llamadas de cola.)

¿Qué hacer cuando un objeto no entiende un mensaje, además de fallar? Una opción es reenviarlo a otro objeto. Motivación: un vendedor (seller) que ofrece productos, y un intermediario (broker) que no conoce los precios y simplemente le reenvía las consultas.

Reenviar explícitamente cada mensaje es tedioso: hay que anticipar todos los mensajes que el broker podría recibir y, para cada uno, escribir el reenvío. Lo automatizamos con una macro OBJECT-FWD cuyo dispatcher, si no encuentra el método localmente, reenvía el mensaje a un objeto target:

Se pueden encadenar reenvíos tan largos como se quiera y terminar en un objeto raíz que no entienda nada (análogo a la clase Object de Java).

El forwarding falla cuando queremos que el intermediario refine el comportamiento del vendedor. Supongamos un broker que quiere duplicar los precios redefiniendo unit a 2:

El refinamiento no surte efecto. El broker recibe price, lo reenvía al seller, y cuando el seller ejecuta price y hace (→ self unit), ese self es el seller (self estático: letrec respeta el alcance léxico), no el broker. La invocación a unit llega a seller-unit, que retorna 1.

La solución es la delegación: self debe ligarse dinámicamente al objeto que originalmente recibió el mensaje (el receptor, o rcvr). En ausencia de alcance dinámico, lo logramos pasando self como parámetro de los métodos, y parametrizando el objeto entero por su receptor:

Cada método es ahora (λ (self) (λ args body)): primero recibe el self, luego sus argumentos reales. Al aplicarlo, le pasamos rcvr como self. Y al delegar en parent, le pasamos el mismo rcvr, de modo que el padre también trate al receptor original como self. La parametrización por self hace innecesario el letrec. La macro de envío de mensajes también debe cambiar, porque ahora el objeto espera primero a su receptor, que es el mismo objeto:

El let evita evaluar o dos veces. (obj obj) significa "aplica el objeto pasándose a sí mismo como receptor de las llamadas a self". Con un objeto raíz que no entiende nada:

Supongamos que necesitamos crear 100 puntos unidimensionales con (make-point init-x). Cada objeto obtiene su propia copia de los métodos, aunque su código fuente es idéntico. Con 100 puntos tenemos 100 getters y 100 setters en memoria: uso de memoria lineal en la cantidad de instancias.

¿Son "los mismos" métodos? No exactamente: cada clausura cierra sobre su propio x y su propio self. El código es igual, pero computacionalmente difieren solo por las variables que capturan. Aquí aparece un patrón: hay una parte común (nombre, argumentos y cuerpo de los métodos) y una parte variable (el contenido de los campos y el self). Factorizar significa sacar la parte común afuera de los objetos: eso es una clase.

Para factorizar los métodos, hay que parametrizarlos por lo que varía: los campos y el self. La estrategia: los métodos se parametrizan por self, y self pasa a encargarse del estado mediante dos mensajes predefinidos, read y write, sobre una tabla hash de campos. Así los métodos se definen una sola vez (capturados en la función constructora) y cada instancia mantiene solo su estado. Queda todavía una redundancia: cada objeto tiene su propia copia del dispatcher.

Al mover también el dispatcher a la función constructora, make-point deja de ser una simple fábrica y se convierte en una clase. Una clase es responsable de: crear instancias, manejar el acceso a campos (read/write) e invocar métodos. Una instancia queda reducida al mínimo: su clase y sus valores.

Representamos una instancia con una estructura de dos campos. define-struct es análogo a deftype: genera el constructor make-obj y los accesores obj-class y obj-values.

La clase es una función recursiva (necesita referirse a sí misma al crear instancias) que responde a los mensajes create, read, write e invoke. Los métodos, parametrizados por self, se definen una sola vez:

Un método se invoca en dos pasos: cdr found) (first args aplica la lambda del método al self (la instancia, (first args)), y apply le pasa los argumentos restantes ((cddr args)). Que cada instancia sea (make-obj class …​) con referencia a class es lo que reduce el objeto a "su clase más su estado".

Generalizamos con la macro CLASS, y factorizamos hacia macros auxiliares las partes no esenciales: el acceso a campos (? y !, que solo manipulan la tabla hash) y la aplicación del método (que se mueve a →), dejando en la clase solo la responsabilidad esencial: el lookup del método.

→ pide a la clase el método ('lookup 'm), lo aplica al self (la instancia o) y luego a los argumentos. Las macros ? y ! capturan self (existe porque los métodos están parametrizados por él). Ahora se programa como es habitual:

Al mover read/write a las macros ? y !, y definir estas localmente dentro de los cuerpos de método (con local), obtenemos encapsulación fuerte: es imposible acceder a los campos de un objeto desde afuera; solo se puede interactuar por paso de mensajes (si el objeto ofrece getters/setters). Usar ? o ! fuera de un método es un error de sintaxis, porque necesitan capturar self.

Podemos también soportar inicialización al estilo constructor, exigiendo un método initialize que reciba tantos argumentos como campos. La función new los reenvía a create:

Y el manejador de create invoca initialize cuando se le pasan argumentos:

Definimos la raíz de la jerarquía. No usa la macro CLASS: es solo un dispatcher que no entiende mensajes (y anticipa el mensaje all-fields que necesitaremos):

Modificamos CLASS para recibir la palabra clave extends y la expresión de la superclase. Ahora, cuando lookup no encuentra el método localmente, lo delega a la superclase en vez de fallar:

Con esto, una subclase que sobrescribe un método funciona correctamente:

El self dinámico se mantiene: el lookup puede encontrar el método en cualquier clase de la jerarquía, pero el método siempre queda parametrizado por self, y el self que se le pasa es siempre la instancia receptora original.

Enfocarse solo en el lookup deja un problema con la creación. Una subclase que no declara campos crearía instancias sin los campos heredados:

La solución no es copiar los campos a mano (la jerarquía puede ser profunda). Hacemos que cada clase sepa responder all-fields con todos sus campos, en orden jerárquico: primero los de la superclase, luego los propios. Con let* para poder encadenar las definiciones:

Como Root responde all-fields con la lista vacía y cada clase antepone los campos de su superclase, fields queda ordenada de ancestros a descendientes. La creación usa entonces todos los campos: (make-obj class (make-hash fields)).

¿Qué pasa si una subclase declara un campo con el mismo nombre que un ancestro (field shadowing)? Con una tabla hash no hay solución: las claves duplicadas colapsan en una sola. Un método alojado en la superclase terminaría leyendo el valor de la subclase (late binding de campos, indeseable):

La semántica correcta: un objeto puede tener valores distintos para campos del mismo nombre, y el método debe usar el campo de su clase anfitriona (la que aloja el método). Representamos esto en dos lugares: la clase guarda la lista de nombres de campos (con repetidos), y la instancia guarda un vector de valores alineado por posición. Necesitamos una función que encuentre la última ocurrencia de un nombre (la más derivada por defecto, o la de la clase anfitriona vía su lista de campos estática):

La creación construye el vector de valores, y las macros ?/! acceden por posición usando find-last sobre la lista de nombres de su clase anfitriona, que está capturada estáticamente. Esta es la versión definitiva de CLASS (Clase 29), que integra herencia, shadowing y —como veremos— super-sends:

Ahora el shadowing es correcto. Nótese la separación clave: el índice se busca en la lista fields de la clase anfitriona (estática, capturada en la definición), pero el vector siempre es el de self (la instancia receptora original, dinámica):

A veces, al refinar un método en una subclase, queremos invocar la versión de la superclase (por ejemplo, para hacer algo antes o después). Eso es un super-send. Motivación: un contador reactivo que, al incrementarse, ejecute automáticamente una reacción. Refinamos inc para llamar al inc original vía sup y luego reaccionar:

La macro sup es (((scls 'lookup 'md) self) . args): busca el método en scls (la superclase), lo aplica a self y a los argumentos.

Con el refinamiento por super-send, el contador reactivo reacciona de forma automática:

Recorrimos toda la orientación a objetos con un mismo hilo conductor —las macros—:

Todo esto se ofrece al programador como una interfaz uniforme y limpia que oculta la codificación interna, y como las clases e instancias son valores de primera clase de Racket, heredamos gratis fábricas de objetos, almacenamiento en estructuras y paso como argumentos.