INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA (ESIME)

UNIDAD CULHUACAN

INGENIERÍA EN COMPUTACIÓN

ASIGNATURA: COMPILADORES

PROFESORA: RESENDIZ COLIN PILAR

“CAPITULO 5: JAVACC”

ALUMNA:

FRANCO GONZÁLEZ MONSERRAT DESIREH

GRUPO: 5CV34

1
 INTRODUCCION

Características generales………………………………………………………………………...……………………………………3

Ejemplo preliminar………………………………………………………………………………………………………………………3

Los programas Java………………………………………………………………………………………………………………………4

Opciones………………………………………………………………………………………………………………………………………5

Área de tokens……………………………………………………………………………………………………………………………6

Caracteres especiales para patrones JavaCC…………………………………………………………………………………7

Elementos accesibles en una acción léxica……………………………………………………………………………………7

La clase Token y el token manager…………………………………………………………………………………………………8

Área de funciones BNF…………………………………………………………………………………………………………………8

Gestión de errores…………………………………………………………………………………………………………………………8

Versiones antiguas de JavaCC………………………………………………………………………………………………………...9

Versiones modernas de JavaCC………………………………………………………………………………………………………9

La utilidad JJTree…………………………………………………………………………………………………………………………9

Renombrado de nodos mediante #...................................................................................................10

Construcción del Árbol…………………………………………………………………………………………………………………10

Tipos de Nodos……………………………………………………………………………………………………………………………10

Node Scope Hooks………………………………………………………………………………………………………………………10

El ciclo de vida de un nodo…………………………………………………………………………………………………………11

Visitor Support……………………………………………………………………………………………………………………………11

Parámetros de Ejecución………………………………………………………………………………………………………………12

Estados en JTree…………………………………………………………………………………………………………………………13

Manual de Referencia de JJDoc……………………………………………………………………………………………………13

2
Características generales
 Genera analizadores descendentes, permitiendo el uso de gramáticas de propósito general
y la utilización de atributos tanto sintetizados como heredados durante la construcción del
árbol sintáctico.
 Las especificaciones léxicas y sintácticas se ubican en un solo archivo. De esta manera la
gramática puede ser leída y mantenida más fácilmente. No obstante, cuando se
introducen acciones semánticas, recomendamos el uso de ciertos comentarios para
mejorar la legibilidad.
 Admite el uso de estados léxicos y la capacidad de agregar acciones léxicas incluyendo un
bloque de código Java tras el identificador de un token.
 Incorpora distintos tipos de tokens: normales (TOKEN), especiales (SPECIAL_TOKEN),
espaciadores (SKIP) y de continuación (MORE). Ello permite trabajar con especificaciones
más claras, a la vez que permite una mejor gestión de los mensajes de error y advertencia
por parte de JavaCC en tiempo de meta compilación.
 Los tokens especiales son ignorados por el analizador generado, pero están disponibles
para poder ser procesados por el desarrollador.
 La especificación léxica puede definir tokens de manera tal que no se diferencien las
mayúsculas de las minúsculas bien a nivel global, bien en un patrón concreto.
 Adopta una notación BNF propia mediante la utilización de símbolos propios de
expresiones regulares, tales como (A)*, (A)+
 Genera por defecto un analizador sintáctico LL
 De entre los generadores de analizadores sintácticos descendentes, JavaCC es uno de los
que poseen mejor gestión de errores. Los analizadores generados por JavaCC son capaces
de localizar exactamente la ubicación de los errores, proporcionando información
diagnóstica completa.
 Permite entradas codificadas en Unicode, de forma que las especificaciones léxicas
también pueden incluir cualquier carácter Unicode. Esto facilita la descripción de los
elementos del lenguaje, tales como los identificadores Java que permiten ciertos
caracteres Unicode que no son ASCII.
 Permite depurar tanto el analizador sintáctico generado como el lexicográfico, mediante
las opciones DEBUG_PARSER, DEBUG_LOOKAHEAD, y DEBUG_TOKEN_MANAGER.
 JavaCC ofrece muchas opciones diferentes para personalizar su comportamiento y el
comportamiento de los analizadores generados.
 Incluye la herramienta JJTree, un preprocesador para el desarrollo de árboles con
características muy potentes.
 Incluye la herramienta JJDoc que convierte los archivos de la gramática en archivos de
documentación.
 Es altamente eficiente, lo que lo hace apto para entornos profesionales y lo ha convertido
en uno de los metas compiladores más extendidos (quizás el que más, por encima de
JFlex/Cup).

Ejemplo preliminar

3
Al igual que con Cup, comenzaremos nuestra andadura con un ejemplo preliminar que dé idea de
la estructura de un programa de entrada a JavaCC y de la notación utilizada para ello

Los programas Java

Los programas JavaCC se suelen almacenar en ficheros con extensión. jj

lo que producirá los ficheros de salida:

 Ejemplo.java: es el analizador sintáctico.

 EjemploTokenManager.java: es el analizador lexicográfico.
 EjemploConstants.java: interface que asocia un código a cada token.

Asimismo, almacena en forma de String el nombre dado por el desarrollador a cada token, además
de las clases necesarias:

 ParseException.java: clase que implementa los errores sintácticos. Cuando el analizador

sintáctico encuentra uno de estos errores genera una excepción que puede ser capturada
en cualquier nodo ancestro del árbol sintáctico que se estaba construyendo.
 SimpleCharStream.java: clase que implementa los canales de entrada de los cuales puede
leer el analizador léxico. Incorpora constructores para convertir los canales de tipo
tradicional: InputStream y Reader.
 Token.java: clase que implementa el objeto a través del cual se comunican el analizador
léxico y el sintáctico.

4
  TokenMgrError.java: clase que implementa los errores lexicográficos. Este tipo de errores
no se puede capturar de forma fácil, por lo que el desarrollador debe recoger todos los
lexemas posibles y generar sus propios errores ante los incorrectos.

Estructura de un programa en JavaCC

Como puede verse en el ejemplo propuesto, la estructura básica de un programa JavaCC es:

options {
Área de opciones
} PARSER_BEGIN(NombreClase)
Unidad de compilación Java con la clase de nombre Nombreclase
PARSER_END(NombreClase)
Área de tokens
Área de funciones BNF

El área de opciones permite especificar algunas directrices que ayuden a JavaCC a generar
analizadores léxico-sintácticos bien más eficientes, bien más adaptados a las necesidades
concretas del desarrollador.

Opciones
Esta sección comienza con la palabra reservada options seguida de una lista de una o más
opciones entre llaves. Las opciones pueden especificarse tanto en el archivo de la gramática como
en la línea de comandos.

Los nombres de las opciones se escriben en mayúsculas, finalizan en ";" y se separan del valor que
se les asocia mediante el signo "=". A continuación, se detallan brevemente las opciones más
importantes y las funciones que realizan:

LOOKAHEAD: indica la cantidad de tokens que son tenidos en cuenta por el analizador
sintáctico antes de tomar una decisión

5
 CHOICE_AMBIGUITY_CHECK: sirve para que JavaCC proporcione mensajes de error más
precisos cuando se encuentra con varias opciones con un prefijo de longitud igual o
superior a la de LOOKAHEAD.
FORCE_LA_CHECK: uno de los principales problemas que puede encontrarse JavaCC en la
construcción del analizador sintáctico radica en la existencia de prefijos comunes en
distintas opciones de una misma regla, lo que hace variar el número de tokens de
prebúsqueda necesarios para poder escoger una de estas opciones.
STATIC: si el valor es true (valor por defecto), todos los métodos y variables se crean como
estáticas tanto en el analizador léxico como en el sintáctico lo que mejora notablemente
su ejecución.
DEBUG_PARSER: esta opción se utiliza para obtener información de depuración en tiempo
de ejecución del analizador sintáctico generado
BUILD_PARSER: indica a JavaCC si debe generar o no la clase del analizador sintáctico. Su
valor por defecto es true, al igual que el de la opción BUILD_TOKEN_MANAGER, lo que
hace que se generen ambos analizadores.
IGNORE_CASE: si su valor es true, el analizador lexicográfico generado no efectúa
diferencia entre letras mayúsculas y minúsculas a la hora de reconocer los lexemas. Es
especialmente útil en el reconocimiento de lenguajes como HTML. Su valor por defecto es
false.
OMMON_TOKEN_ACTION: si el valor de esta opción es true, todas las invocaciones al
método getNextToken () de la clase del analizador lexicográfico, causan una llamada al
método CommonTokenAction() después del reconocimiento de cada lexema y después de
ejecutar la acción léxica asociada, si la hay. El usuario debe definir este último método en
la sección TOKEN_MGR_DECLS del área de tokens. El valor por defecto es false.
UNICODE_INPUT: si se le da el valor true se genera un analizador léxico capaz de gestionar
una entrada codificada en Unicode. Por defecto vale false lo que asume que la entrada
estará en ASCII.
OUTPUT_DIRECTORY: es una opción cuyo valor por defecto es el directorio actual.
Controla dónde son generados los archivos de salida

Área de tokens
permite la construcción de un analizador lexicográfico acorde a las necesidades particulares de
cada proyecto. JavaCC diferencia cuatro tipos de tokens o terminales, en función de lo que debe
hacer con cada lexema asociado a ellos:

 SKIP: ignora el lexema.

 MORE: busca el siguiente el siguiente lexema, pero concatenándolo al ya recuperado.
 TOKEN: obtiene un lexema y crea un objeto de tipo Token que devuelve al analizador
sintáctico (o a quien lo haya invocado). Esta devolución se produce automáticamente sin
que el desarrollador deba especificar ninguna sentencia return en ninguna acción léxica.
 SPECIAL_TOKEN: igual que SKIP, pero almacena los lexemas de tal manera que puedan ser
recuperados en caso necesario. Puede ser útil cuando se construyen traductores fuente-
fuente de manera que se quieren conservar los comentarios a pesar de que no influyen en
el proceso de traducción

6
Donde:

 La palabra TOKEN puede sustituirse por SKIP, MORE o SPECIAL_TOKEN.

 La cláusula [IGNORE_CASE] es opcional, pero, si se pone, no deben olvidarse los corchetes.
 El patrón puede ir precedido de un nombre de token y separado de éste por dos puntos,
pero no es obligatorio.
 Si el patrón es una constante entrecomillada sin token asociado pueden omitirse los
paréntesis angulares que lo engloban y, por tanto, el nombre.
 Los estados léxicos son identificadores cualesquiera, preferentemente en mayúsculas, o
bien la palabra DEFAULT que representa el estado léxico inicial. Pueden omitirse. También
puede indicarse una lista de estados léxicos separados por comas.
 Si se omite el estado léxico antes de la palabra TOKEN quiere decir que los patrones que
agrupa pueden aplicarse en cualquier estado léxico.
 Si se omite el estado léxico tras un patrón quiere decir que, tras encontrar un lexema que
encaje con él, se permanecerá en el mismo estado léxico.
 Las acciones léxicas están formadas por código Java y son opcionales.
 Las acciones léxicas tienen acceso a todo lo que se haya declarado dentro de la cláusula
opcional TOKEN_MGR_DECLS.
 Las acciones léxicas se ejecutan en el seno de un token manager tras recuperar el lexema
de que se trate.
 JavaCC sigue las mismas premisas que PCLex a la hora de buscar lexemas, esto es, busca
siempre el lexema más largo posible y, en caso de que encaje por dos patrones, opta por
el que aparezca en primer lugar.
 Si JavaCC encuentra un lexema que no encaja por ningún patrón produce un error léxico.

Caracteres especiales para patrones JavaCC

Los caracteres que tienen un significado especial a la hora de formar expresiones regulares son:

“”: sirve para delimitar cualquier cadena de caracteres

<>: sirve para referenciar un token definido previamente.
*: indica repetición 0 ó más veces de lo que le precede entre paréntesis
+: indica repetición 1 ó más veces de lo que le precede entre paréntesis.
?: indica que lo que le precede entre paréntesis es opcional.
|: indica opcionalidad. Ej.: (“ab” | “cd”) encaja con “ab” o con “cd”
[]: sirve para expresar listas de caracteres. En su interior pueden aparecer:
 Caracteres sueltos encerrados entre comillas y separados por comas.
 Rangos de caracteres formados por dos caracteres sueltos entre comillas y separados por
un guion.
 Cualquier combinación de los anteriores.

~[]: sirve para expresar una lista de caracteres complementaria a la dada según lo visto
anteriormente para [].

7
Elementos accesibles en una acción léxica
El desarrollador puede asociar acciones léxicas a un patrón que serán ejecutadas por el analizador
léxico cada vez que encuentre un lexema acorde. En estas acciones se dispone de algunas
variables útiles, como son:

 image: variable de tipo StringBuffer que almacena el lexema actual.

 lenghtOfMatch: variable de tipo entero que indica la longitud del último lexema
recuperado.
 curLexState: variable de tipo entero que indica el estado léxico actual.
 matchedToken: variable de tipo Token que almacena el token actual.
 switchTo(int estadoLéxico): función que permite cambiar por programa a un nuevo
estado léxico. Si se invoca esta función desde una acción léxica debe ser lo último que ésta
ejecute

La clase Token y el token manager

Como ya se ha comentado, cada vez que el analizador léxico encuentra un lexema
correspondiente a un token normal, retorna un objeto de la clase Token. Las variables y funciones
principales de esta clase son:

 image: variable de tipo String que almacena el lexema reconocido.

 kind: para cada patrón al que el desarrollador le asocia un nombre, JavaCC incluye una
constante de tipo entera en la clase de constantes que genera. La variable kind almacena
uno de dichos enteros, concretamente el del nombre del patrón por el que encajó su
lexema.
 beginLine, beginColumn, endLine y endColumn: variables de tipo entero que indican,
respectivamente la línea y columna de comienzo y de final del lexema.
 specialToken: variable de tipo Token que referencia al token anterior si y sólo si éste era
de tipo especial; en caso contrario almacenará el valor null.

Para finalizar, hay que indicar que JavaCC proporciona en la clase del analizador léxico dos
métodos que pueden ser interesantes, caso de querer construir tan sólo dicho analizador, a saber:

o Un constructor que toma como parámetro un objeto de tipo CharStream del que tomará
la entrada a analizar.
o La función getNextToken() que devuelve el siguiente objeto de tipo Token que encuentra
en la entrada. El desarrollador debe controlar el tipo de token para no consumir más allá
del fin de la entrada.

Área de funciones BNF

8
JavaCC genera un analizador sintáctico descendente implementado a base de funciones recursivas,
de manera que cada no terminal de nuestra gramática será convertido una función diferente, cuya
implementación será generada por JavaCC.

Por otro lado, las expresiones BNF exprBNF pueden hacer uso de los siguientes componentes:

noTerminal(): representa la utilización del no terminal noTerminal. Nótese la utilización de los

paréntesis de invocación de función

<>: permiten hacer referencia a un terminal declarado en el área de tokens.

“”: permiten expresar tokens anónimos, entrecomillando un literal de tipo cadena de caracteres.
*: indica repetición 0 ó más veces de lo que le precede entre paréntesis.
+: indica repetición 1 ó más veces de lo que le precede entre paréntesis.
?: indica que lo que le precede entre paréntesis es opcional.
[]: tiene igual significado que el ?, ¿de manera que (patrón)? es equivalente a [patrón].
|: indica opcionalidad
Gestión de errores
La gestión de errores puede conseguirse en JavaCC en dos vertientes:

Personalizando los mensajes de error.

Recuperándose de los errores

Versiones antiguas de JavaCC

JavaCC proveerá a la clase del analizador sintáctico con las variables:

error_line, error_column: variables de tipo entero que representan la línea y la columna

en la que se ha detectado el error

9
 error_string: variable de tipo String que almacena el lexema que ha producido el error. Si
la prebúsqueda (lookahead) se ha establecido a un valor superior a 1, error_string puede
contener una secuencia de lexemas.
expected_tokens: variable de tipo String[] que contiene los tokens que habrían sido
válidos. De nuevo, si la prebúsqueda se ha establecido a un valor superior a 1, cada ítem
de expected_tokens puede ser una secuencia de tokens en lugar de un token suelto

De manera parecida, en el analizador léxico pueden hacerse uso de los elementos:

error_line, error_column: línea y columna del error léxico.

error_after: cadena de caracteres que contiene el trozo de lexema que se intentaba
reconocer.
curChar: carácter que ha producido el error léxico.
LexicalError(): función invocada por el token manager cuando se encuentra un error
léxico.

Versiones modernas de JavaCC

Esta clase posee las variables:

 currentToken: de tipo Token, almacena el objeto token que ha producido el error.

 expectedTokenSequences: de tipo int[][] tiene el mismo objetivo que la variable
expected_tokens vista en el apartado anterior
 tokenImage: de tipo String[] lmacena los últimos lexemas leídos. Si la prebúsqueda está a
1, entonces se cumple:
tokenImage[0].equals(currentToken.image);

La utilidad JJTree
JJTree es el preprocesador para JavaCC. Inserta acciones que construyen árboles parser en la
fuente JavaCC. La salida generada por JJTree se ejecuta a través de JavaCC para crear el parser.

Características
Por defecto, JJTree genera código para construir el árbol de nodos del parse para cada no terminal
de nuestro lenguaje JJTree define una interfaz de Java tipo Node, el cual todos los nodos del árbol
parser deben implementar. JJTree puede operar de dos formas distintas: simple o multi

Renombrado de nodos mediante #

# es un constructor que se utiliza para que el usuario pueda llamar a cada nodo de una forma
distinta a como JavaCC le llama por defecto.

Construcción del Árbol

Aunque JavaCC es un generador de gramáticas descendente, JJTree construye el árbol de la
secuencia de reglas gramaticales desde abajo, es decir, de forma ascendente.

10
Tipos de Nodos
JJTree proporciona decoraciones para dos tipos básicos de nodos, además de algunas
simplificaciones sintácticas para facilitar su uso.

1. Un nodo se construye con un número definido de hijos. Recordemos que a un nodo padre
se le asocian uno o más nodos hijos que son sacados de la pila e introducidos de nuevo en
ella, pero formando parte de la estructura del padre. Un nodo definido se puede crear de
la siguiente manera:
 INTEGER EXPRESSION puede ser cualquier tipo de expresión entera. Lo más común es
que dicha expresión sea una constante (de tipo entero).
2. Un nodo condicional se construye con todos los nodos hijos asociados al ámbito del padre
siempre que la condición del padre se evalúe a true. Esto se representa de la siguiente
manera:
 BOOLEAN EXPRESSION puede ser cualquier expresión de tipo boolean. Igual que en el
caso anterior, el nombre que se le da al nodo viene dado por ConditionalNode.

Node Scope Hooks

Esta opción altera el comportamiento de JJTree, de manera que, automáticamente, todos los
tokens reconocidos son capturados.

El ciclo de vida de un nodo

Un nodo pasa por una secuencia determinada de pasos en su generación. La secuencia vista desde
el propio nodo es la siguiente:

1. El constructor del nodo se llama con un único parámetro de tipo entero. Dicho parámetro
nos dice qué tipo de nodo es, siendo esto especialmente útil en modo simple.
2. Se realiza una llamada al método jjtOpen ()
3. Si la opción NODE_SCOPE_HOOK está activa, se llama al método parser definido por el
usuario openNodeScope () y se le pasa el nodo como parámetro.
4. Si una excepción sin manejador se lanza mientras que el nodo se está generando, dicho
nodo se descarta. JJTree nunca volverá a hacer referencia a este nodo.
5. En otro caso, si el nodo es condicional, y su condición se evalúa a false, el nodo se descarta
6. En otro caso, el número de hijos del nodo especificado en la expresión entera del nodo
definido, o todos los nodos que fueron almacenados en la pila en un ámbito de nodo
condicional, son añadidos al nodo (dicho número es la aridad del nodo; si es condicional,
se define #Id(>1)). El orden en el que se añaden no se especifica.
7. Se llama al método jjtClose ()
8. El nodo es almacenado en la pila
9. Si la opción NODE_SCOPE_HOOK está activa, el método parser definido por el usuario
closeNodeScope () se llama y utiliza el nodo como parámetro.
10. Si el nodo no es el nodo raíz, se añade como estructura de hijo a otro nodo y se llama a su
método jjtParent ().

Visitor Support

11
JJTree provee algunos soportes básicos para el patrón de diseño visitor. Si la opción VISITOR está a
true, JJTree añadirá un método jjtAccept () en todas las clases de nodo que genere, además de la
creación de una interfaz de usuario que pueda ser implementada y pasada a los nodos.

Parámetros de Ejecución
JJTree proporciona opciones para la línea de comando y para las opciones de declaraciones de
JavaCC:

1. BUILD_NODE_FILES (true por defecto): genera implementaciones de muestra para

SimpleNode y para cualesquiera otros nodos usados en la gramática.
2. MULTI (false por defecto): genera el árbol parse en modo multi. Cada nodo (no-terminal)
creado y no declarado como void, genera un fichero de nombre nombreNoTerminal.java,
en el cual cada nodo extiende de SimpleNode. Estos ficheros se generan de forma
automática.
3. NODE_DEFAULT_VOID (false por defecto): en vez de crear cada producción no-decorada
como un nodo indefinido, lo crea void en su lugar. Cualquier nodo decorado no se verá
afectado por esta opción.
4. NODE_FACTORY (false por defecto): usa un método de generación para construir nodos
con la siguiente estructura:
public static Node jjtCreate (int id)
5. NODE_PACKAGE ("" por defecto): el paquete para generar el nodo en una clase. Por
defecto, contiene el paquete del parser.
6. NODE_PREFIX ("AST" por defecto): el prefijo usado para construir los nombres de clase del
nodo a partir de los identificadores del nodo en modo multi.}
7. NODE_SCOPE_HOOK (false por defecto): inserta llamadas a los métodos parser definidos
por el usuario en cada entrada y salida de cada ámbito de nodo.
8. NODE_USERS_PARSER (false por defecto): JJTree usará una forma alternativa de las
rutinas de construcción de nodos donde se le pasa el parser del objeto
9. STATIC (true por defecto): genera código para un parser static. Debe ser usado de forma
consecuente con las opciones equivalentes proporcionadas por JavaCC.
10. VISITOR (false por defecto): inserta un método jjtAccept () en las clases del nodo, y genera
una implementación de visitor con una entrada para cada tipo de nodo usado en la
gramática
11. VISITOR_EXCEPTION ("" por defecto): si esta opción está activa, se usa en las estructuras
de los métodos jjtAccept () y visit (). Mucho cuidado porque esta opción se eliminará en
versiones posteriores de JJTree.

Estados en JTree
JJTree mantiene su estado en un campo de la clase del parser llamado jjtree. Se puede usar
métodos en este miembro para manipular la pila del nodo. Algunos de los métodos generados
automáticamente para esta clase están expuestos más arriba. También se indica en qué fichero se
encuentra almacenado el código generado.

12
Manual de Referencia de JJDoc
JJDoc toma la especificación del parser de JavaCC y produce la correspondiente documentación
para la gramática BNF. Puede funcionar de tres formas distintas, dependiendo del comando
introducido en la zona de opciones:

 TEXT: Por defecto, esta opción está a false.Inicializando esta opción a true, JJDoc genera
una descripción simple en formato texto de la gramática en BNF.
 ONE_TABLE: Por defecto, true. El valor por defecto de ONE_TABLE se usa para generar
una única tabla HTML para la notación BNF.
 OUTPUT_FILE: El funcionamiento por defecto es poner la salida de JJDoc en un fichero
junto con la extensión .html o .txt añadida como sufijo al nombre del fichero de entrada.

13