Trabajo Práctico Final

Transcripción

1 Trabajo Práctico Final Paradigmas de Lenguajes de Programación (1er cuatrimestre de 2009) Integrante LU Correo electrónico Castillo, Gonzalo 164/06 gonzalocastillo Martínez, Federico 17/06 Sainz-Trápaga, Gonzalo 454/06 En el siguiente trabajo se presenta la implementación de un intérprete extensible para Cálculo Lambda tipado. A lo largo del mismo se desarrollan las principales problemáticas de implementación, se explica como realizar nuevas extensiones al cálculo y se detallan posibles extensiones al trabajo. Facultad de Ciencias Exactas y Naturales Universidad de Buenos Aires Ciudad Universitaria - (Pabellón I/Planta Baja) Intendente Güiraldes C1428EGA Ciudad Autónoma de Buenos Aires - Rep. Argentina Tel/Fax: (54 11)

2 Índice general 1. Introducción Introducción teórica Objetivos del trabajo Organización del informe Detalles de implementación Lenguaje de programación Definición de extensiones Creación de Tipos Creación de Expresiones Construcción de extensiones Sintaxis Mecanismo de análisis sintáctico Definición de reglas sintácticas Tipado Semántica Tipos y términos básicos Boolean, true y false Abstracciones If Then Else Variables Aplicación Nat Zero Succ

3 Pred iszero Tutorial La extensión Maybe Código boilerplate Creando un nuevo tipo Definición de expresiones básicas Definición de un término derivado simple Definición de un término derivado complejo Creación de la extensión Extensiones Tipos Expresiones Posibles extensiones al trabajo Subtipado Inferencia de tipos y otras alternativas Conclusión 30

4 Castillo, Martínez, Sainz-Trápaga Página 1 de 30 Parte 1 Introducción 1.1. Introducción teórica El Cálculo Lambda es un modelo de computación basado en funciones. Por tratarse de un modelo computacionalmente completo y riguroso en su formulación, se utiliza con frecuencia como herramienta para el estudio de lenguajes de programación y sus propiedades, así como lenguaje de referencia para la definición de semántica en otros lenguajes de programación. La versión del Cálculo Lambda desarrollada en este trabajo es el Cálculo Lambda Tipado (A. Church, ) Objetivos del trabajo El trabajo propuesto consiste en el desarrollo de un intérprete para Cálculo Lambda Tipado, con el foco fijado en la facilidad de extensión del mismo. Durante el cuatrimestre se utilizó una definición básica del Cálculo que se extendió progresivamente agregando nuevas funcionalidades propias de los distintos paradigmas de programación. La idea del intérprete desarrollado era adaptarse al desarrollo propuesto en la materia, de modo que agregar nuevas extensiones al cálculo sea una tarea tan simple como sea posible. La facilidad de extensión se da a través del uso del paradigma orientado a objetos y el uso intensivo de herencia como herramienta de reuso de código, minimizando así la cantidad de líneas necesarias para la creación de una extensión. Dada esta facilidad, debería ser factible incorporar al trabajo como complemento de la materia por la capacidad que provee de permitir a los alumnos interactuar de forma más directa con el modelo. Finalmente, además del sistema básico y fácilmente extensible, se incluyen además con el trabajo la mayoría de las extensiones que fueron propuestas en clase durante el cuatrimestre, y documentación suficiente como para que agregar nuevas extensiones sea una tarea accesible Organización del informe El presente informe se organiza de la siguiente manera: En el apartado 2 se explican los detalles concernientes a la implementación del intérprete, así como las decisiones de diseño que fueron tomadas a la hora de desarrollar. En 3 se detalla paso a paso la construcción de una nueva extensión, con el objetivo de familiarizar al lector con el problema y la solución como la proponemos. En 4 se enumeran las extensiones ya implementadas por nosotros. Por último, en 5 comentamos posibles extensiones o mejoras que podrían realizarse al trabajo. 1 A. Church: A Formulation of the Simple Theory of Types, JSL 5, 1940

5 Castillo, Martínez, Sainz-Trápaga Página 2 de 30 Parte 2 Detalles de implementación 2.1. Lenguaje de programación Para la implementación del intérprete utilizamos el lenguaje de programación Python, en parte por tratarse de un lenguaje con el que estamos acostumbrados a trabajar, pero además porque consideramos que su sintaxis sencilla y limpia es adecuada para facilitar la construcción posterior de extensiones, aún por personas que no estén familiarizadas con el lenguaje Definición de extensiones Conceptualmente, el intérprete concibe a un lenguaje como una colección de extensiones. Una extensión consta de un nombre apropiado para identificarla, una colección de tipos y una colección de términos, así como las reglas necesarias para darles tipado, sintaxis y semántica a las expresiones del lenguaje extendido. Esta idea reproduce la aproximación ofrecida en clase, en la que se parte de un cálculo básico con algunos elementos esenciales, y sobre el que se van construyendo nuevas estructuras. Como dijimos, la característica principal de esta implementación es que permite agregar extensiones (es decir, tipos y expresiones). Así, en lo que respecta al código, crear nuevas extensiones consiste en subclasear dos clases llamadas Expresion y Tipo que residen en expresion.py Creación de Tipos Para crear un nuevo tipo, se debe heredar de la clase Tipo y asegurarse de implementar los siguientes métodos: init (self, tok): el constructor de una instancia de un tipo, que toma una lista de tokens (ver 2.3) y a partir de estos construye la instancia. En general, al momento de ser procesados por este constructor, los tokens ya fueron procesados y son objetos que representan a su vez a otros tipos (análogo al funcionamiento de un fold), y son necesarios para la creación de tipos recursivos. sintaxis(cls): un classmethod o método estático que define la sintaxis con la que se va a parsear una expresión de tipo 1. eq (self,other): la comparación por igualdad entre tipos, que debe funcionar como la relación unifica. Por defecto la clase padre Tipo considera que un tipo unifica con otro si son de la misma clase, por lo cual si este comportamiento es el esperado no es necesario definirlo (por ejemplo, Nat unifica con Nat, pero para tipos recursivos podría no ser suficiente esta definición). 1 Nota: No confundir expresión de tipo con expresiones tipadas del cálculo. La clase hija de Tipo define la sintaxis que utiliza el lenguaje para referirse al tipo propiamente dicho, por ejemplo, en las declaraciones de funciones. La sintaxis de los términos que tipan a este tipo es competencia de las clases hijas de expresión, que se detallan más adelante

6 Castillo, Martínez, Sainz-Trápaga Página 3 de 30 str (self): (optativo) el equivalente a tostring en otros lenguajes, que se utiliza para imprimir por pantalla a las instancias de la clase Creación de Expresiones Para crear una nueva expresión válida dentro del lenguaje, se debe heredar de la clase Expresion y asegurarse de implementar los siguientes métodos: init 2.3). (self, tok): el constructor, que construye una instancia de la expresión a partir de una lista de tokens (ver sintaxis(cls): análogo a la extensión de tipos, este método estático define la sintaxis de una expresión de esta clase (ver 2.3). reducir(self): implementa la semantica de la expresión (ver 2.5). tipar(self, namespace): implementa las reglas de tipado de la expresión (ver 2.4). sustituir(self, var, expresion): implementa las reglas de sustitución para las instancias, donde var es el nombre de una variable a ser reemplazada por expresion. Es aquí donde se determina, entre otras cosas, el scope de las variables. str (self): (optativo) el equivalente a tostring en otros lenguajes, que se utiliza para imprimir por pantalla a las instancias de la clase Construcción de extensiones Finalmente, una extensión se modela como una instancia de la clase Extensión, que se construye a partir de una etiqueta, una lista de expresiones y una lista de tipos. Los elementos de la listas son las clases que mencionamos previamente. Así, puede construirse un lenguaje a partir de una serie de extensiones que se cargan o descargan dinámicamente. El procedimiento se detalla con mayor precisión en Sintaxis Mecanismo de análisis sintáctico Uno de los problemas principales a resolver para permitir la posterior definición de extensiones era como facilitar la definición de la sintaxis de los nuevos términos sin obligar al usuario a interactuar de forma directa con el parser utilizado. El desafío consistió además en dar una forma sencilla de definir la sintaxis, pero sin imponer restricciones innecesarias a la complejidad de las extensiones que podrían definirse. Las herramientas que conocemos que permiten definir sintaxis y semántica de forma combinada y sin demasiado código de por medio son las de Gramáticas de Atributos y Traducción Dirigida por Sintaxis. Sin embargo, consideramos que lidiar con las particularidades de las gramáticas libres de contexto era algo a evitar, por lo que buscamos una alternativa más simple. La solución elegida es intermedia. Por un lado, se logró que definir la sintaxis (y su correspondiente semántica) sea relativamente sencillo, abstrayendo la mayor parte del código común, y manteniendo una sintaxis medianamente simple. Por otra parte, varios de los helpers introducidos para simplificar la creación de extensiones pueden omitirse para así tener más flexibilidad a la hora de trabajar. Esto se debe a que dichos helpers se definen en su mayoría como funciones auxiliares que están débilmente acopladas al resto del intérprete, siendo así su uso totalmente optativo. El parser elegido corresponde a la familia de parsers recursivos descendentes, y utilizamos la implementación de la librería PyParsing por el uso excelente que hace de la sobrecarga de operadores y de las capacidades de alto nivel de Python para permitir la definición amigable de reglas gramaticales utilizando Python de forma directa, sin recurrir a definicies externas en otros lenguajes. El parser utiliza backtracking, porque de otro modo sería imposible permitir añadir de forma simple nuevas reglas sintácticas que podrían introducir ambigüedades en parsers recursivos. Este problema proviene del hecho de que los parsers recursivos descendentes son una familia similar a los LL(1), y por tanto lidian de forma limitada con los posibles prefijos de

7 Castillo, Martínez, Sainz-Trápaga Página 4 de 30 una definición gramatical. Si bien algunos de los problemas de los parsers LL(1) se eliminan a costa de usar backtracking, otros persisten: no es posible utilizar recursión a izquierda en la definición de reglas. Esta es una limitación propia del mecanismo de parsing que nos obligó a realizar algunas modificaciones en el lenguaje aceptado por el intérprete. Así, por ejemplo, para el caso de la aplicación, la producción: Exp Exp Exp no puede ser parseada por este procedimiento (dado que el programa entraría en un bucle infinito hasta terminar por stack overflow. Por lo tanto, en su lugar proponemos: Exp (Exp Exp) La gramática sigue siendo ambigua, pero al eliminar la recursión a izquierda mediante la introducción de paréntesis, el parser puede eliminar la ambiguedad utilizando alguna heurística de decisión (sea first-match o longest-match, según lo que uno considere más conveniente). Esto elimina una preocupación a la hora de definir nuevas extensiones. Por último, es importante mencionar que las expresiones del lenguaje, a excepción de los términos de tipo y las variables, no deberán utilizar letras mayúsculas ya que este criterio se utiliza para diferenciar entre sí a estos diferentes elementos Definición de reglas sintácticas Como se mencionó antes, es el método estático sintaxis() para expresiones el que devuelve el lado derecho de una producción que se utilizará al momento de parsear una expresión. Este lado derecho se asocia al no terminal Exp de la gramática, que es el símbolo inicial que produce todos los términos del lenguaje, y puede ser usado en la definición de la sintaxis para referirse (recursivamente) a cualquier termino. Su análogo TipoExp caracteriza a las expresiones de tipos y puede a su vez usarse en las definiciones de sintaxis. Para la definición de la sintaxis se pueden utilizar directamente las distintas clases que provee PyParsing, y sobre las que hay excelente documentación en el sitio web correspondiente. Por ejemplo, la sintaxis del if resultaría: Exp if Exp then Exp else Exp Utilizando las clases de PyParsing: Keyword( if ).suppress() + Exp + Keyword( then ).suppress() + Exp + Keyword( else ).suppress() + Exp Nótese que la sintaxis es simple, utilizando el operando de suma para la concatenación y las referencias a Exp cuando es necesario indicar que en ese lugar aparece una expresión arbitraria. La lista de tokens que se construye a partir de esa expresión es la que luego recibe el constructor de la expresión para instanciar un objeto. El método suppress() elimina el token después de hallarlo porque no resulta de interés para su utilización posterior (puesto que no contiene información). Así, se eliminan todos los strings fijos de la expresión conservando así solo las subexpresiones, que son las que interesan al momento de construir una instancia del objeto correspondiente a la expresión if. Nótese que no es necesario utilizar suppress(), pero de no hacerlo se deberán ignorar los tokens en el constructor de la expresión. Sin embargo, para sintaxis simples puede usarse el helper expresion.makesintaxis(*args), que recibe como parámetros los componentes sintácticos para armar la producción. Asi por ejemplo, para definir la sintaxis del if: makesintaxis( if,exp, then,exp, else,exp) La función makesintaxis transforma las cadenas de letras en Keywords, las cadenas que contengan símbolos en Literals, y las Exp (o cualquier otra instancia de parseelement) las mantiene, y devuelve la expresión que resulta de la concatenación

8 Castillo, Martínez, Sainz-Trápaga Página 5 de 30 de todas ellas. Si bien sintaxis más complejas (como el caso de los registros con campos nombrados) no pueden definirse con makesintaxis, por lo que será necesario utilizar el método anterior, más extenso pero más flexible. Como se dijo anteriormente, al parsear una expresión segun esta sintaxis, se pasan los tokens al constructor para construir el objeto apropiado. Los tokens son todos las instancias de parseelement que no tengan suppress activado. En el caso del if, los tokens son las tres instancias de Exp. Notar que al constructor del if llegará entonces una lista con tres elementos que son los resultados de haber parseado recursivamente las 3 expresiones (y por lo tanto son instancias de alguna subclase de Expresion) Tipado Dado que implementamos un lambda calculo tipado, un elemento fundamental en la definicion de nuevas expresiones son las reglas de tipado. El metodo debe devolver una instancia de alguna subclase de Tipo indicando el tipo correspondiente o debe generar TypeException en caso de que el termino no tipe. Para definir reglas de tipado se puede usar el = entre tipos, por esta razón es necesario que las subclases de Tipo implementen un eq adecuado a su semántica. La función tipar recibe ademas como parámetro el contexto de tipado, que funciona como diccionario de nombre de variable (string) a su tipo Semántica La semántica en nuestra implemetanción está dada por el método reducir. Esta reducción es del tipo big-step, es decir si un termino tipa, una llamada a reducir debe devolver el valor al que reduce. A la hora de definir la semántica, puede asumirse como precondición que el término tipa, ya que el intérprete chequea previamente que la expresión tipe antes de intentar reducirla. Es importante asegurarse de que si el termino tipa, la reducción no deberia fallar. De esta manera el método reducir debe devolver la instancia de expresión que resulta de reducir completamente al término Tipos y términos básicos En esta sección presentaremos los tipos básicos vistos en clase junto con su implementación para nuestro lenguaje. Consideraremos como tipos básicos a los booleanos, los naturales y a las funciones. Es interesante notar que éstos no son objetos privilegiados dentro de la jerarquía del intérprete, y se definen exactamente de la misma manera en que se definiría cualquier extensión. Sin embargo, por su naturaleza esencial, son requeridos por casi todas las demás extensiones y por tanto son de interés especial Boolean, true y false Términos M ::= true false

9 Castillo, Martínez, Sainz-Trápaga Página 6 de 30 Reglas de tipado Γ true : Bool Γ false : Bool Semántica Las expresiones true y false son valores, no reducen. Implementación Esta implementación, por su sencillez, hace uso de otros dos helpers apropiados para la construcción de tipos básicos (no paramétricos) y átomos de algún tipo particular. Se trata de las funciones simpletypefactory (que crea una clase apropiada a partir de la sintaxis del término de tipo) y atomofactory (que crea una clase hija de Expresion a partir de su sintaxis simple y la clase correspondiente a su tipo). Estas dos funciones se utilizan en varias ocasiones cuando es necesario definir casos sencillos, ahorrando así la repetición innecesaria de código en los lugares donde no es necesaria la flexibilidad. Boolean = simpletypefactory( Boolean ) Verdadero = atomofactory( true, Boolean) Falso = atomofactory( false, Boolean) Abstracciones Términos M ::=... λx : σ.m Reglas de tipado Γ, X : σ M : τ Γ λx : σ.m : σ τ Semántica Las abstracciones son valores, no reducen.

10 Castillo, Martínez, Sainz-Trápaga Página 7 de 30 Implementación class Func(Tipo): def init (self,tok): Define para el tipo funcion el dominio y la imagen. dom, img = tok self.dominio = dom self.imagen = img def eq (self, other): Un tipo es igual a un tipo funcion, si es de tipo funcion y sus dominios e imagenes son iguales. return self. class == other. class and \ self.dominio == other.dominio and \ self.imagen == def sintaxis(cls): Abs = makesintaxis( (, TipoExp, ->, TipoExp, ) ) return Abs def str (self): s1 = str(self.dominio) s2 = str(self.imagen) if self.dominio. class == self. class : return "( %s) -> %s" % (s1, s2) return " %s -> %s" % (s1, s2) class Abstraccion(Expresion): def init (self, toks): Una Abstraccion se compone por un id que representa una variable, un tipo para esa variable y un expresion. var, tipo, expresion = toks self.var = var self.tipovar = tipo self.expresion = expresion def reducir(self): Una Abstraccion reduce a si misma, es un valor. return self def tipar(self, namespace): gamma,{x:alpha} > M : beta gamma > \X:alpha.M : (alpha -> beta) nam2 = dict(namespace) nam2[self.var] = self.tipovar return Func([self.tipoVar, self.expresion.tipar(nam2)])

11 Castillo, Martínez, Sainz-Trápaga Página 8 de 30 def sustituir(self, var, expresion): \X:alpha.M {X <- T} --> \X:alpha.M \X:alpha.M {Y <- T} --> \X:alpha.(M {Y <- T}) si X!= Y if self.var!= var: expresion = self.expresion.sustituir(var, expresion) return Abstraccion([self.var, self.tipovar, expresion]) return def sintaxis(cls): Abs = makesintaxis( \\, return Abs Id, :, TipoExp,., Exp) def str (self): return "\\ %s : %s. %s" % (self.var, self.tipovar, self.expresion) If Then Else Términos M ::=... if M then P else Q Reglas de tipado Γ M : Bool, Γ P : σ, Γ Q : σ Γ if M then P else Q : σ Semántica M M if M then P else Q if M then P else Q if true then P else Q P if false then P else Q Q

12 Castillo, Martínez, Sainz-Trápaga Página 9 de 30 Implementación class IfThenElse(Expresion): def init (self, toks): Define para la estructura IfThenElse la guarda y las ramas por verdadero y por falso. guarda, ramatrue, ramafalse = toks self.guarda = guarda self.ramatrue = ramatrue self.ramafalse = ramafalse def reducir(self): Reducción de la guarda a un valor. Luego dependiendo de dicho valor se reduce la rama verdadera o la falsa. if isinstance(self.guarda.reducir(), Verdadero): return self.ramatrue.reducir() return self.ramafalse.reducir() def tipar(self, namespace): gamma > Guarda : Boolean, gamma > RamaTrue : alpha, gamma > RamaFalse : alpha gamma > if Guarda then RamaTrue else RamaFalse : alpha tipoguarda = self.guarda.tipar(namespace) tiporamatrue = self.ramatrue.tipar(namespace) tiporamafalse = self.ramafalse.tipar(namespace) # gamma > Guarda : Boolean if tipoguarda == Boolean([]): # gamma > RamaTrue : alpha, gamma > RamaFalse : alpha if tiporamatrue == tiporamafalse: # gamma > if Guarda then RamaTrue else RamaFalse : alpha return tiporamatrue raise TypeException( Tipo rama true: %s \n % tiporamatrue + \ Tipo rama false: %s \n % tiporamafalse + \ No existe unificación entre los tipos de las ramas. ) raise TypeException( Tipo de la guarda: %s \n % tipoguarda + \ El tipo de la guarda no unifica con Boolean. ) def sustituir(self, var, expresion): if M then N else O {X <- T} --> if M {X <- T} then N {X <- T} else O {X <- T}. guarda = self.guarda.sustituir(var, expresion) ramatrue = self.ramatrue.sustituir(var, expresion) ramafalse = self.ramafalse.sustituir(var, expresion) return IfThenElse([guarda, ramatrue, def sintaxis(cls):

13 Castillo, Martínez, Sainz-Trápaga Página 10 de 30 # if M then N else O If = makesintaxis( if, Exp, then, Exp, else, Exp) return If def str (self): return "if %s then %s else %s" % (self.guarda, self.ramatrue, self.ramafalse) Variables Términos Ψ es un conjunto infinito enumerable de variables, X Ψ, M ::=... X Reglas de tipado {X : σ} Γ Γ X : σ Semántica Las variables no reducen, tienen que ser sustituídas. Implementación class Variable(Expresion): def init (self, tok): Las variables se inicializan con un identificador compuesto por un string con el primer caracter en mayuscula. self.id = tok[0] def reducir(self): Las variables reducen a si mismas, tiene que ser sustituidas. return self def tipar(self, namespace): {X : alpha} pertenece a gamma gamma > X : alpha if not (self.id in namespace): for each in namespace:

14 Castillo, Martínez, Sainz-Trápaga Página 11 de 30 print each, namespace[each], each. class raise TypeException(( No es posible determinar el tipo de la variable %s a + \ partir del contexto: %s. ) % (self.id, namespace)) return namespace[self.id] def sustituir(self, var, expresion): X {X <- T} --> T X {Y <- T} --> X si X!= Y if self.id == var: return expresion return def sintaxis(cls): Id = Regex( [A-Z][a-zA-Z]* ) return Id def str (self): return self.id Aplicación Términos M ::=... M N Reglas de tipado Γ M : σ τ, Γ N : σ Γ M N : τ Semántica M M M N M N N N V N V N (λx : σ.m)v M{X V }

15 Castillo, Martínez, Sainz-Trápaga Página 12 de 30 Implementación class Aplicacion(Expresion): def init (self, toks): Una aplicacion esta compuesta por una funcion aplicadora y un parametro. aplicador, parametro = toks self.aplicador = aplicador self.parametro = parametro def reducir(self): Se reduce la funcion aplicadora y el parametro, luego: (\X:alpha.M V) --> M {X <- V} Finalmente se sustituye M {X <- V} y se reduce M. aplicador = self.aplicador.reducir() parametro = self.parametro.reducir() res = aplicador.expresion.sustituir(aplicador.var, parametro) return res.reducir() def tipar(self, namespace): gamma > M: (alpha -> beta), gamma > N: alpha gamma > (M N) : beta x = self.aplicador.tipar(namespace) z = self.parametro.tipar(namespace) if isinstance(x, Func): if x.dominio == z: return x.imagen raise TypeException(( Tipo del aplicador: %s \n + \ Tipo del parametro: %s \n + \ El tipo del parametro no se corresponde con el domino del tipo del aplicador. (x' x) raise TypeException(( Tipo del aplicador: %s \n + \ El tipo del aplicador no se corresponde con el tipo de una Abstraccion. ) % def sustituir(self, var, expresion): (M N) {X <- T} --> (M {X <- T} N {X <- T}) aplicador = self.aplicador.sustituir(var, expresion) parametro = self.parametro.sustituir(var, expresion) return Aplicacion([aplicador, def sintaxis(cls): App = makesintaxis( (, Exp, White().suppress(), Exp, ) ) return App

16 Castillo, Martínez, Sainz-Trápaga Página 13 de 30 def str (self): return "( %s %s)" % (str(self.aplicador), str(self.parametro)) Nat Implementación Nat = simpletypefactory( Nat ) Zero Términos M ::=... zero Reglas de tipado Γ zero : Nat Semántica zero no reduce, es un valor. Implementación Zero = atomofactory( zero, Nat) Succ Términos M ::=... succ(m)

17 Castillo, Martínez, Sainz-Trápaga Página 14 de 30 Reglas de tipado Γ M : Nat Γ succ(m) : Nat Semántica M M succ(m) succ(m ) Implementación class Succ(Expresion): def init (self, toks): Define para estructura succ la expresion que contiene. self.termino = toks[0] def reducir(self): Reducir succ(e) corresponde a reducir E. terminored = self.termino.reducir() return Succ([terminoRed]) def tipar(self, namespace): gamma > E : Nat gamma > succ(e) : Nat if self.termino.tipar(namespace) == Nat([]): return Nat([]) raise TypeException(( El tipo %s de la expresion: %s \n + \ no se corresponde con el tipo Nat. ) % (self.termino.tipar(namespace), self.termino)) def sustituir(self, var, expresion): succ(e) {X <- T} --> succ(e {X <- T}) return Succ([self.termino.sustituir(var, def sintaxis(cls): succ = makesintaxis( succ(, Exp, ) ) return succ def str (self):

18 Castillo, Martínez, Sainz-Trápaga Página 15 de 30 return "succ( %s)" % self.termino Pred Términos M ::=... pred(m) Reglas de tipado Γ M : Nat Γ pred(m) : Nat Semántica M M pred(m) pred(m ) pred(succ(m)) M pred(zero) zero Implementación class Pred(Expresion): def init (self, toks): Define para estructura succ la expresion que contiene. self.termino = toks[0] def reducir(self): Se reduce primero el la expresion que contiene pred, luego: pred(zero) --> zero pred(succ(v)) --> v

19 Castillo, Martínez, Sainz-Trápaga Página 16 de 30 termino = self.termino.reducir() if isinstance(termino, Zero): return termino return termino.termino def tipar(self, namespace): gamma > E : Nat gamma > pred(e) : Nat if self.termino.tipar(namespace) == Nat([]): return Nat([]) raise TypeException(( El tipo %s de la expresion: %s \n +\ no se corresponde con el tipo Nat. ) % (self.termino.tipar(namespace), self.termino)) def sustituir(self, var, expresion): pred(e) {X <- T} --> pred(e {X <- T}) return Pred([self.termino.sustituir(var, def sintaxis(cls): pred = makesintaxis( pred(, Exp, ) ) return pred def str (self): return "pred( %s)" % self.termino iszero Términos M ::=... iszero(m) Reglas de tipado Γ M : Nat Γ iszero(m) : Bool Semántica M M iszero(m) iszero(m )

20 Castillo, Martínez, Sainz-Trápaga Página 17 de 30 iszero(succ(m)) f alse iszero(zero) true Implementación class IsZero(Expresion): def init (self, toks): Se define para la estructura iszero la expresion que contiene. self.termino = toks[0] def reducir(self): Se reduce primero la expresion que contiene iszero, luego: iszero(zero) --> true iszero(succ(v)) --> false termino = self.termino.reducir() if isinstance(termino, Zero): return Verdadero([]) return Falso([]) def tipar(self, namespace): gamma > E : Nat gamma > iszero(e): Boolean if self.termino.tipar(namespace) == Nat([]): return Boolean([]) raise TypeException(( El tipo %s de la expresion %s no se corresponde con el tipo Nat. ) \ % (self.termino.tipar(namespace), self.termino)) def sustituir(self, var, expresion): iszero(e) {X <- T} --> iszero(e {X <- T}) return IsZero([self.termino.sustituir(var, def sintaxis(cls): isz = makesintaxis( iszero(, Exp, ) ) return isz def str (self): return "iszero( %s)" % self.termino

21 Castillo, Martínez, Sainz-Trápaga Página 18 de 30 Parte 3 Tutorial 3.1. La extensión Maybe En este tutorial vamos a realizar paso por paso la extensión que llamamos Maybe, y que nos permite definir un tipo paramétrico Maybe < T > que tiene dos constructores: Nothing < T > y Just J (donde J es un término de tipo T). Para construir la extensión, tenemos que: crear el tipo crear las expresiones básicas Nothing y Just crear una función simple: isnothing crear una función más compleja: casemaybe crear la extensión propiamente dicha y registrarla con el intérprete 3.2. Código boilerplate Para crear la nueva extensión creamos un nuevo archivo de texto vacío en la carpeta extensiones (idealmente con extensión.py) y pegamos el siguiente código en él: #!/usr/bin/python # -*- coding: utf8 -*- from expresion import Expresion, Tipo, Exp, TipoExp, TypeException from expresion import makesintaxis from booleans import Boolean from lenguaje import Extension Como verán, se trata de una serie de imports de objetos que vamos a necesitar referenciar en nuestro código. Expresion y Tipo son las clases de las que vamos a heredar para construir los términos y tipos de nuestra extensión (que se construye a partir de la clase Extension, que importamos al final de todo). Exp y TipoExp son los patrones de sintaxis de PyParsing que podemos usar al definir sintaxis para referirnos a una expresión cualquiera o n término de tipo cualquiera. TypeException es la excepción que debemos producir cuando haya un error de tipos Finalmente, Boolean es la clase que corresponde al tipo homónimo (y por tanto vive en la extensión correspondiente). Es

22 Castillo, Martínez, Sainz-Trápaga Página 19 de 30 necesaria porque más adelante vamos a necesitar indicarle al sistema de tipado que un término es de tipo Boolean ( adivinan cual?), y para esto es necesario instanciar dicha clase Creando un nuevo tipo En este caso no se puede utilizar el helper simpletypefactory porque este no es un tipo simple : se trata de un tipo paramétrico, y por lo tanto hay que definirlo a mano extendiendo directamente la clase Tipo. Comencemos entonces por definir la sintaxis: ####################################### # Declaración del nuevo tipo Maybe(T) # ####################################### class def sintaxis(cls): return makesintaxis( Maybe(, TipoExp, ) ) Esta declaración decorada (la línea que comienza se llama decorator en Python) crea un método estático de la clase TipoMaybe (que luego se llama como TipoMaybe.sintaxis()). En este caso utilizamos el helper makesintaxis para decirle al intérprete que un término que describe al tipo TipoMaybe tiene la sintaxis Maybe(TipoExp), donde TipoExp representa a una expresión de tipo cualquiera (por ejemplo, Nat, Bool o incluso Maybe(Nat)!). La definición sin makesintaxis hubiera sido más larga y difícil de leer(y además hubiera sido necesario importar Literal desde pyparsing!): return Literal( Maybe( ).suppress() + TipoExp + Literal( ) ).suppress() Veamos ahora como se construye una instancia de TipoMaybe: def init (self, toks): self.tipo = toks[0] La construcción es simple, únicamente se almacena como un atributo de instancia el primer elemento de la lista toks, que corresponde al primer y único token que matchea la sintaxis del tipo (recordemos que como se utiliza suppress() implícitamente sobre los chunks Maybe( y ), estos no serán recibidos por el constructor). Sigamos: def eq (self, otro): return self. class == otro. class and \ self.tipo == otro.tipo Un T ipomaybe < T > será igual a otro si el segundo es un TipoMaybe (esa es la implementación heredada de la clase Tipo, y no sería necesario sobrecargarla si fuera ésta la definición), pero también si el tipo englobado por el Maybe es igual al otro. Recordemos que si bien se utiliza el operador de igualdad, la noción asociada al mismo es la de unificación. def str (self): return Maybe( %s)" % self.tipo Finalmente, el último método define la forma en que se convierte el objeto a una representación en forma de string amigable para el usuario. En este caso (y en todos los demás), nos limitamos a reproducir la sintaxis. Con esto ya tenemos el nuevo tipo definido, y podemos dedicarnos a construir los términos asociados al mismo.

23 Castillo, Martínez, Sainz-Trápaga Página 20 de Definición de expresiones básicas A continuación vamos a definir las dos expresiones básicas del tipo Maybe(T), empezando por Nothing (y esta vez heredando de Expresion en lugar de Tipo). ###################################### # Declaración de nuevas expresiones # ###################################### class def sintaxis(cls): return makesintaxis( nothing(, TipoExp, ) ) La definición de sintaxis es análoga a la definición de sintaxis en el término de tipo. Hay dos particularidades para notar en esta definición. La primera es que la expresión que definimos como nothing(t) consta de una variable de tipo(denotada por TipoExp) que permite tipar la expresión. En segundo lugar, no hay que olvidar que los términos no deben llevar mayúsculas (ya que el parser asume que las cosas que comienzan por mayúsculas dentro de una expresión son variables). Por esta razón, el átomo creado se llama nothing(t) y no Nothing(T). def init (self, toks): self.tipo = toks[0] def str (self): return nothing( %s) % self.tipo Tanto el constructor como la función de conversión a string son exactamente iguales a las de la definición del tipo y por tanto no requieren explicación adicional. Veamos ahora qué ocurre con las funciones propias de la clase Expresion. def reducir(self): return self La función reducir() es responsable de producir un término reducido (con semántica big-step) a partir de la expresión actual. Sin embargo, en el caso de Nothing y por tratarse de un valor, no hay que hacer ninguna reducción y es suficiente con devolver una referencia al propio objeto que recibe el mensaje. def tipar(self, namespace): return TipoMaybe([self.tipo]) La función tipar() se encarga de producir una instancia del tipo correspondiente a esta expresión. Para esto, nos servimos de la clase que definimos anteriormente que instanciamos parametrizada en el tipo que parseamos a partir de la sintaxis. Así, convertimos nothing(nat) en una instancia de T ypemaybe < Nat >. Nótese la peculiaridad de que TipoMaybe recibe una lista de tokens, y por lo tanto se debe pasar como parámetro [self.tipo] (entre corchetes). def sustituir(self, var, expresion): return self Finalmente, el mecanismo de sustitución, por tratarse de un átomo inmutable, se limita a devolver una referencia al propio objeto sin sustituir nada (ya que no pueden aparecer variables dentro de esta expresión). Veamos ahora la definición de Just J:

24 Castillo, Martínez, Sainz-Trápaga Página 21 de 30 class def sintaxis(cls): return makesintaxis( just(, Exp, ) ) En este caso la diferencia respecto de la definición de nothing reside en que la subexpresión es un término convencional y no una declaración de tipo. Esto es posible puesto que a partir de dicho término se podrá inferir su tipo y así establecer el tipado de esta expresión. Esto se refleja en la utilización de Exp en lugar de TipoExp dentro de la definición de sintaxis. def init (self, toks): self.exp = toks[0] def str (self): return just( %s) % self.exp def reducir(self): e = self.exp.reducir() return Just([e]) La definición de reducción se ajusta a lo definido por el Cálculo Lambda: si M M luego Just(M) Just(M ). Esto es precisamente lo que se establece aquí, con una llamada recursiva a reducir() de la expresión hija. def tipar(self, namespace): return TipoMaybe([self.exp.tipar(namespace)]) def sustituir(self, var, expresion): return Just([self.exp.sustituir(var, expresion)]) Estos dos últimos casos son análogos al anterior: la implementación no hace más que llamar recursivamente a las funciones apropiadas en la subexpresión y construir a partir de dichos resultados los datos que le fueron pedidos. Con esta última clase disponemos ya de los términos básicos que constituyen al tipo paramétrico Maybe T. Sin embargo, para su uso posterior será conveniente declarar algunos términos adicionales que faciliten su utilización Definición de un término derivado simple A continuación nos concierne la declaración de la expresión isnothing(e) que reduce a true si E es Nothing, o a false si E es Just J. Veamos su implementación:

25 Castillo, Martínez, Sainz-Trápaga Página 22 de 30 class def sintaxis(cls): return makesintaxis( isnothing(, Exp, ) ) def init (self, toks): self.exp = toks[0] def str (self): return isnothing( %s) % self.exp def reducir(self): e = self.exp.reducir() if isinstance(e,nothing): return Verdadero([]) return Falso([]) def sustituir(self, var, expresion): return IsNothing([self.exp.sustituir(var, expresion)]) Hasta este punto las definiciones son análogas a las vistas anteriormente. Sin embargo, la implementación del tipado es más novedosa: def tipar(self, namespace): st = self.exp.tipar(namespace) if isinstance(st, TipoMaybe): return Boolean([]) raise TypeException( Tipo del Término: %s \n + El tipo del término debe ser Maybe(T). % st) Observando la lógica del código, vemos que lo que hace es tipar el subtérmino (es decir, si estamos lidiando con isnothing(e), obtiene el tipo de E) y a continuación se fija si dicho tipo es realmente Maybe, verificando si es una instancia de TipoMaybe. En caso afirmativo, el tipo de la expresión isnothing será Boolean, clase de la que se devuelve una instancia. De otro modo, se envía una TypeException indicando de forma informativa el error que se produjo, cual era el tipo esperado y cual el que se recibió Definición de un término derivado complejo Como última declaración analizaremos la implementación de CaseMaybe, el observador en base a constructores de las instancias de Maybe < T >. class def sintaxis(cls): return makesintaxis( casemaybe(, TipoExp, ), Exp, ; of nothing ->, Exp, ; just(j) ->, Exp) def init (self, toks): self.tipo, self.exp, self.resnothing, self.resjust = toks def str (self): return casemaybe( %s) %s; of nothing -> %s; just(j) -> %s % \ (self.tipo, self.exp, self.resnothing, self.resjust) Hasta este punto no se observan diferencias significativas. Es de notar que para simplificar el ejemplo se utilizó el nombre

26 Castillo, Martínez, Sainz-Trápaga Página 23 de 30 fijo J para la variable del case. def reducir(self): expr = self.exp.reducir() if isinstance(expr, Nothing): return self.resnothing.reducir() return self.resjust.sustituir( J, expr.exp).reducir() La primera diferencia que se observa entre esta extensión y la anterior se da en el caso de la reducción: en este caso, es necesario para reducir exitosamente ligar la variable J a la expresión asociada. Esto es precisamente lo que hace el código si detecta que la expresión interna (self.exp) es una instancia de Just. def tipar(self, namespace): maybet = self.exp.tipar(namespace) trn = self.resnothing.tipar(namespace) ns nuevo = namespace.copy() ns nuevo[ J ] = self.tipo trj = self.resjust.tipar(ns nuevo) if isinstance(maybet, TipoMaybe) and trn == trj: return trn raise TypeException(( Tipo del Término: %s \n + Tipo del bloque Case Nothing: %s \n + Tipo del bloque Case Just: %s \n + El tipo de ambos casos debe ser compatible, y el tipo del término debía ser Maybe(T). )' (maybet, trn, trj)) La implementación de la regla de tipado es similar a la que vimos en isnothing, aunque el chequeo a realizar es más complejo (ya que deben asegurarse más condiciones). En este caso, se verifica que ambas ramas del case tengan el mismo tipo después de ligar la variable J en el caso de Just, así como que self.exp tenga el tipo apropiado según la declaración del case. Una peculiaridad es el uso del namespace: nótese que a diferencia de los casos anteriores, el contenido del mismo se modifica. El namespace es un diccionario nativo de Python, que mapea strings a instancias de subclases de Tipo. Dado que los diccionarios (al igual que prácticamente todo en Python) se pasan por referencia, es necesario copiar el namespace explícitamente antes de realizar la modificación del mismo ya que de otro modo se corre el riesgo de contaminar el namespace de otras expresiones que compartan la misma instancia del diccionario. def sustituir(self, var, expresion): smaybe = self.exp.sustituir(var, expresion) sresnothing = self.resnothing.sustituir(var, expresion) if var!= J : sresjust = self.resjust.sustituir(var, expresion) sresjust = self.resjust return CaseMaybe([self.tipo, smaybe, sresnothing, sresjust]) Por último, el mecanismo de sustitución también es más complejo: en este caso, y como hay una variable ligada por esta expresión, debe asegurarse de que no se realice una sustitución de la misma por pedido de una expresión de nivel más alto. En este punto se establece el scope de la variable J, y se determina que su valor dentro del bloque correspondiente

27 Castillo, Martínez, Sainz-Trápaga Página 24 de 30 del case será establecido por self.reducir() y no por una sustitución anterior. Así, frente a un pedido de sustitución, se reemplazará cualquier variable menos J, que es local puesto que se define a nivel del Case Creación de la extensión Finalmente, el único punto pendiente es la creación de la extensión propiamente dicha. El código es autoexplicativo: no hay más que instanciar la clase Extension con una etiqueta apropiada. ###################################### # Armado de la nueva extensión # ###################################### extensionmaybe = Extension( Maybe, expresiones=[just, Nothing, IsNothing, CaseMaybe], tipos=[tipomaybe]) Por último, para que la extensión sea detectada por los aplicativos (tanto de consola como la interfaz gráfica, es necesario agregarla a la lista extensiones en registro.py. Esta lista es consultada por las aplicaciones para conocer las extensiones que están disponibles.

28 Castillo, Martínez, Sainz-Trápaga Página 25 de 30 Parte 4 Extensiones Los siguientes son los tipos y expresiones definidos por nosotros a modo de librería Tipos Boolean Natural Función (σ τ) Registro Lista Árbol Binario Maybe Tupla (Par ordenado) 4.2. Expresiones Booleanos: True False if M then P else Q Naturales: zero succ(m) pred(m) iszero(m) Funciones: Variables λx : T.M Aplicación (M N) Registros: construcción de registros proyección de registros Listas: Lista vacía agregar elemento adelante (add(e,l)) case para listas (esquema para pattern matching)

29 Castillo, Martínez, Sainz-Trápaga Página 26 de 30 Arboles binarios: nil constructor de árbol binario (bin(m,n,o)) case para arboles Maybe Nothing Just isnothing case para Maybe Tuplas constructor de tupla proyectores

30 Castillo, Martínez, Sainz-Trápaga Página 27 de 30 Parte 5 Posibles extensiones al trabajo 5.1. Subtipado Una ampliación posible para el trabajo sería la incorporación de reglas de subtipado. Esto es factible dentro del esquema propuesto, y la forma simple de hacerlo sería sobrecargar el operador < para los tipos. De este modo, en vez de preguntar si un tipo es igual a otro, se pregunta por menor o igual al momento de realizar los chequeos de tipos. El siguiente código implementa la extensión de registros: class TypeReg(Type): El tipo registro estara compuestos por etiquetas con tipos asociados. def init (self, tok ): i = 0 ids = {} while(i < len(tok)): ids[tok[i]] = tok[i+1] i = i + 2 self.ids = ids La igualdad de un tipo, con un tipo registro se da si en principio es un registro y sus etiquetas coinciden en todos los tipos con los del otro tipo registo. def eq (self, otro): if isinstance(otro, TypeReg): res = True for each in self.ids: res = res and each in otro.ids and self.ids[each] == otro.ids[each] if(not res): return res return len(self.ids) == len(otro.ids) return def sintaxis(cls): campo = makesintaxis(id, :, TypeExp) listacampos = Optional(campo + ZeroOrMore(makeSintaxis(",", campo)))

31 Castillo, Martínez, Sainz-Trápaga Página 28 de 30 reg = makesintaxis( {, listacampos, } ) return reg def str (self): s = { primero = True for each in self.ids: if primero: primero = False s+= str(each)+ : +str(self.ids[each]) s+=, +str(each)+ : +str(self.ids[each]) s += } return s En el caso de los registros, tenemos reglas de subtipado a lo ancho y a lo largo, que podemos escribir como: {L i 1 i n} {k j 1 j m}, k j = l i S j <: T i {k j : S j 1 j m} <: {l i : T i 1 i n} Este comportamiento puede agregarse a la extensión typereg de esta forma: def le (self, other): determina si un tipo registro es subtipo de otro # other tiene que ser un registro if(isinstance(other,typereg)): res = True #tiene que tener todo lo que tiene el otro for each in other.ids: res = res and (each in self.ids) if not res: return False #cada label compartida tiene que ser subtipo for each in other.ids: res = res and (self.ids[each] < other.ids[each]) return res El principal conflicto con ésto es que habría que modificar el código de las extensiones ya implementadas. Esto es necesario por un lado para que utilicen subtipado según corresponda, y por otro lado porque en algunos casos hay expresiones que deben tipar y que en el modelo utilizado para este trabajo no reducen (y no son valores). Por ejemplo, pred(true) tipa Nat, ya que Bool < Nat, pero no tiene definida ninguna regla de reducción. Esto se podría resolver o bien cambiando el método reducir de pred, o agregando un método a Bool para determinar dado un valor de tipo Bool qué instancia de Nat representa. Asimismo sería necesario construir estas reglas de coercion para varios de los tipos básicos.

32 Castillo, Martínez, Sainz-Trápaga Página 29 de Inferencia de tipos y otras alternativas Durante la cursada vimos como implementar el algoritmo de inferencia de tipos para el cálculo lambda (que además implemetamos en una clase de laboratior). Por esta razón, decidimos usar tipado simple y no inferencia de tipos para enfocarnos en el aspecto central de nuestro trabajo que era la simplicidad de extensión. Del mismo modo, podría construirse como extensión futura el agregado de polimorfismo, así como también junto con este considerar el desarrollo de clases de tipos (similares a las de Haskell, donde tenemos Eq para denotar que los tipos tienen comparación por igual, o Show para denotar a los tipos que tienen una funcion show para ser mostrados por pantalla).

33 Castillo, Martínez, Sainz-Trápaga Página 30 de 30 Parte 6 Conclusión Como conclusión final podemos enumerar una serie de conceptos que resultaron de la realización de este trabajo práctico. En primer lugar, y como se explicó en la introducción, la idea de este trabajo era poder lograr un intérprete de lambda cálculo que no sólo funcionara de manera correcta, sino que también pudiese ser extendido para incluir nuevos tipos y expresiones de forma sencilla. Consideramos que este objetivo se cumplió, ya que pudimos elaborar una manera estándar de introducir nuevas extensiones al intérprete. Además, consideramos que hallamos un equilibrio razonable entre la sencillez de extensión y la flexibilidad que se permite al agregar nuevos términos al lenguaje. No se utilizaron conveciones extremadamente fuertes que podrían haber causado limitaciones poco prácticas para extender el lenguaje de forma extravagante. A su vez, la inclusión del tutorial debería hacer que la incorporación de una nueva extensión sea un procedimiento sencillo incluso para aquellas personas que no están familiarizadas con el trabajo ni con el lenguaje Python. Por otro lado creemos que el enfoque del trabajo se orientó a uno de los temas más importantes de la cursada, y que se logró no sólo combinarlo con programación orientada a objetos, sino también encontrar una forma dinámica de resolverlo. Si bien es cierto que durante la cursada se implementaron cuestiones relacionadas al lambda cáculo, la visión de éste trabajo es más compacta y abarca las cuestiones principales del tema (como ser el manejo de tipado, sintaxis, reducción y extensiones al cálculo). Además, los trabajos prácticos llevados a cabo durante la cursada tuvieron enfoques menos globales que éste, que nos permitió construir un intérprete de un lenguaje de programación de principio a fin. Como señalamos en el apartado anterior, nos hubiese gustado también implementar otras cuestiones como es el caso de las reglas de subtipado. Sin embargo, se dejaron las puertas abiertas a dicha extensión como se comentó anteriormente. Consideramos que como punto final a la materia, la realización de un trabajo práctico constituyó una solución dinámica e interactiva, y nos permitió utilizar lo aprendido para construir una herramienta completa, que podría tener posibilidades de uso futuro dentro de la materia. Futuros estudiantes pueden examinar el código entregado para comprender el funcionamiento de un intérprete, y servirse de la gran cantidad de extensiones propuestas como referencia para implementar las suyas.