Compilador del lenguaje MOOL que genera código Objective Caml Ruben Gonzalez Castro 1 1 Instituto Tecnológico de Culiacán, Av. Juan de Dios Batíz s/n Col. Guadalupe, Culiacán, Sin. 80220 México Tel. 667-713 3804 ruben_culiacan@hotmail.com Abstract. El diseño del lenguaje de programación MOOL fue presentado por la Dra. Maria Lucia Barrón Estrada durante la defensa de su tesis para obtención del grado. MOOL es un lenguaje basado en clases, orientado a objetos con soporte a programación modular y genérica. Por otra parte, el lenguaje Objective Caml desarrollado por el instituto INRIA maneja además de las características funcionales, interesantes elementos en común con el lenguaje MOOL. Este artículo se centra en la implementación de un compilador hecho en lenguaje Java que traduce código MOOL en código de Objective Caml. Keywords:Lenguajes de Programacion, Implementacion, Compiladores, Ocaml, MOOL. 1 Introduccion El lenguaje MOOL [1] es un nuevo lenguaje de programación orientado a objetos con soporte a módulos, polimorfismo paramétrico y genéricos. Sus siglas en ingles son Modular Object Oriented Language. Fue diseñado para soportar el desarrollo tanto de pequeños programas como de grandes aplicaciones a través de la interconexión de módulos e interfaces de módulos. Por otra parte, el lenguaje de programación Objective Caml (también llamado Ocaml), fue creado por la Institut National de Recherche en Informatique et en Automatique (INRIA), puede ser descargado y utilizado libremente desde el sitio http://caml.inria.fr/. Este lenguaje de programación ofrece varias características, de las cuales, a continuación se mencionan solo aquellas que comparte con el lenguaje de programación MOOL: Programación Imperativa. Orientado a Objetos. Soporte a Módulos (Interfase e implementación). Basado en Clases (Interfase e implementación). Soporte a Genéricos. Con todos estos elementos comunes y con la ayuda de herramientas generadoras de Scanner, Parser y árboles de sintaxis abstracta, el desarrollo de un compilador del lenguaje MOOL que genere código de OcaML es una buena alternativa para la implementación de este nuevo lenguaje.
module interface MIGenStack { //MOOL class interface IGenStack <T>{ T pop(); void push(t elem); boolean empty (); } class GenStack<T> implements IGenStack<T> { constructors GenStack<T> (); Module type STACK=sig (* Ocaml *) type a t exception Empty val create : unit -> a t -> unit val push : a -> a t -> unit Fig. 1. Ejemplos de codigo en MOOL y Ocaml 3 Metodologia usada Durante el desarrollo del proyecto fue usada la herramienta JavaCC [5] para la generación del analizador léxico y analizador de semántica, además de la herramienta Java Tree Builder (JTB) [4] que se integra al JavaCC para la generación de las clases Java encargadas de la generación del árbol de sintaxis abstracta. La herramienta JavaCC toma como entrada un archivo de texto que contiene la gramática del lenguaje MOOL en un formato EBNF (Extended Backus Naur Form), y
genera la salida formada por varios archivos y directorios, mismos que contienen las clases Java para realizar el análisis sintáctico y semántico. El archivo de especificaciones semánticas para JavaCC consiste de una serie de reglas gramaticales, dichas reglas se pueden asociar a una acción semántica con código Java, de forma tal que cuando el analizador de Parser encuentra una regla dada, ejecuta el código Java asociado. En este sentido, usamos la herramienta JTB, la cual toma de entrada el archivo con las especificaciones sintácticas del JavaCC para incrustarle a las reglas semánticas, el código Java necesario para la generación del árbol de sintaxis abstracta. Para agregarle modularidad a nuestro compilador, separamos en directorios o paquetes Java las tareas relacionadas con los análisis léxico, semántico y traducción. Una forma de lograr esto es que el Parser produzca un árbol de parser, dicha estructura puede ser recorrida en fases posteriores del compilador. El árbol de parser contiene exactamente una hoja o nodo por cada token de la entrada y un nodo interno para cada regla gramatical reducida durante el análisis sintáctico. Ocamool.jjt Especificaciones lexicas Y sintácticas (formato EBNF) JTB + Ocamool.out.jjt Generación del Árbol de Sintaxis Abstracta JavaCC Visitantes Análisis Léxico Ánalisis Sintactico Árbol Sintáctico Tablas de Símbolos Manejo de Errores Fig. 2. Integración del JTB con el JavaCC. 3.1 El patron de diseño del Visitante JavaCC y JTB generan las clases Java para la construcción del árbol de sintaxis abstracta (no es recomendable su modificación), cada una de estas clases contiene los métodos que facilitan su recorrido a través métodos visit. Este método tiene como
única función delegar el control a los métodos apropiados del visitante. De esta forma el visitante invoca los métodos accept de un nodo y pregunta Cuál es tu clase? ; el método accept responde invocando el correspondiente método visit de la clase Visitante. Cada visitante implementa la interfaz Visitor, de tal forma que cada método accept recibe como argumento un Visitor y a su vez, cada método visit recibe como argumento un nodo del árbol de sintaxis abstracta. El patrón de diseño visitor nos permite definir una nueva operación sobre la estructura de un objeto sin necesidad de cambiar su código fuente. En lugar de escribir métodos para el análisis semántico, chequeo de tipos y traducción, en cada una de las clases que forman el árbol de sintaxis, se implementan estas funcionalidades en nuestras clases mediante los adecuados métodos accept. 3.2 Fases del Compilador Los compiladores realizan su tarea [2],[6],[7] y [8] a través de cuatro principales tareas o fases al momento de traducir un archivo de texto que contiene código fuente Análisis Léxico (Scanner) Análisis Sintáctico (Parser) Análisis Semántico Generación de código (Traducción) Con el fin de realizar una traducción más directa entre MOOL y Ocaml, deliberadamente se han omitido algunas fases a nuestro compilador tales como la generación de código intermedio, código maquina y la optimización.. La primera fase, o análisis léxico, realiza un barrido secuencial al archivo de entrada para extraer las palabras y/o símbolos significativos llamados Tokens, tales como palabras reservadas, símbolos de puntuación y las literales tales como números y cadenas de caracteres. El análisis Sintáctico es la fase de la compilación en la cual se extrae el significado de los tokens, se asegura la correcta sintaxis del programa fuente y se construye una representación interna del programa. En esta fase, el compilador examina el código fuente y lo compara con respecto a las reglas definidas en la gramática del lenguaje. Si el código fuente viola alguna regla gramatical, el compilador despliega un mensaje de error. Un compilador que usa la estructura de datos llamada árbol de sintaxis abstracta no necesita hacer todas las fases en una sola pasada. La fase del análisis Semántico sigue a la fase del análisis Sintáctico y toma como entrada el árbol de análisis gramatical creado en la fase del análisis Sintáctico. Esta fase determina el significado del programa mediante la tabla de símbolos verificando cuáles de las variables han sido definidas; en esta fase se lleva a cabo la verificación estática de tipos [7]. La tabla de símbolos se encarga de asociar los identificadores con sus tipos y ubicaciones al momento que el analizador sintáctico procesa la declaración de un identificador. La tabla de símbolos para verificación semántica se estructura mediante cinco clases, que nos permiten mantener la información de todos los identificadores
que se encuentran dentro del programa de MOOL. Estas tablas de simbolos se muestran en la figura siguiente. Fig. 3. Clases que integran las Tablas de simbolos La verificación semántica se produce en dos pasos o recorridos, el primero sucede cuando se cargan los elementos (identificadores, funciones, constructores, etc.) a la tabla de símbolos, validando la existencia previa o ausencia de tales elementos. En el segundo recorrido se realiza el chequeo (estático) de los elementos usando la información de la tabla de símbolos. Una vez que el análisis sintáctico termina libre de errores, ya existe en memoria una representación interna del código fuente más fácil de recorrer y sintetizar para generar el código objeto de OCaml. El proceso de la traducción o generación de código se realiza mediante un tercer recorrido (de tipo DepthFirts) al árbol de sintaxis abstracta generado en las fases anteriores. El compilador reconoce cada una de las diferentes producciones que conforman la gramática del lenguaje MOOL y la convierte a la producción correspondiente del lenguaje OCaml. Esta traducción se realiza a través de una clase que implementa la interfaz Visitor; la cual contiene los métodos Visit sobrecargados para recibir un objeto de diferentes tipos, un tipo para cada una de las producciones del lenguaje MOOL. 3.3 Traducción Como un ejemplo de traducción podemos mencionar la producción ProgramUnit que cuya gramática en MOOL se define como: nodechoice -> ModuleInterface() ModuleImplementation() Esto significa que esta producción se puede derivar en una ModuleInterface ó en una ModuleImplementation, por lo que la clase encargada de la traducción deberá contar con un método visit, el cual recibe como parámetro un objeto del tipo ProgramUnit.
Siguiendo con este ejemplo, si el analizador sintáctico deriva una producción del tipo ModuleInterface, se delega el flujo del compilador al metodo visit que recibe un objeto de este tipo. } /* nodetoken -> <MODULE> nodetoken1 -> <INTERFACE> nodetoken2 -> <ID> moduleblock -> ModuleBlock() */ public void visit(moduleinterface n) { // código para la traducción del ModuleBlock o cuerpo // de la interface de Módulo O bien, si la producción ProgramUnit del mismo ejemplo se tratase de una implementación del modulo, la traducción vendría dada por la misma gramática de MOOL: /* nodetoken -> <MODULE> nodetoken1 -> <ID> moduleinterfaces -> ModuleInterfaces() moduleblock -> ModuleBlock() */ public void visit(moduleimplementation n) { } // código para traducir el cuerpo o ModuleBlock // de la implementación del módulo. La traducción final en Ocaml para la producción ProgramUnit de MOOL puede darse en una de las tres posibles archivos fuentes: Module Signature (.mli) Module Structure (.ml) Functors (.ml) 4.- Conclusiones y trabajos futuros. Este proyecto fue analizado y desarrollado con la finalidad de implementar un compilador para un nuevo lenguaje recién diseñado, y de paso demostrar la
combinación o mezcla de diferentes paradigmas de lenguajes de programación. El lenguaje MOOL combina los paradigmas modular y orientado a objetos tomando en cuenta los genéricos y el manejo de tipos, mientras que el lenguaje Objective Caml desde sus orígenes es funcional y posteriormente se le han agregado características de genéricos, orientado a objetos y recientemente el manejo de módulos. En la fase de implementación actual, nos encontramos en la traducción de un conjunto reducido de las construcciones del lenguaje MOOL a Ocaml, por lo que los trabajos futuros se centrarán en la traducción de la gramática completa, incluyendo elementos tales como el manejo de cadenas de caracteres, polimorfismo y genéricos. 5.- Bibliografía [1] MOOL: An Object-Oriented Programming Language with Generics and Modules. PhD. Maria Lucia Barron Estrada. Doctoral Dissertation mayo-2004. [2] Modern Compiler Implementation in Java. Andrew W. Appel. Ed. Cambridge University Press 1998. [3] Sitio Oficial del lenguaje OcaML http://caml.inria.fr/ [4] Sitio oficial del Java Tree Builder http://compilers.cs.ucla.edu/jtb/jtb- 2003/index.html [5] Sitio oficial del Java Compiler Compiler http://www.metamata.com/javacc/ [6] Compiladores Principios, técnicas y herramientas Alfred V. Aho,Ravi Sethi, Jeffrey D. Ullman; Addison Weley 1990 [7] Fundamentos de Compiladores: Cómo Traducir al lenguaje de la computadora. Karen A. Lemone. Editorial CECSA 1996. [8] Design of Compilers: Techniques of Programming language Translation. Karen A. Lemone. Library of Congress Cataloging-in-Publication Data [9] Manual de referencia de Objective Caml versión 3.08 http://wwwtcs.inf.tudresden.de/~tews/htmlman-3.08