Semantico.apun

4o Ingenier´ Inform´tica
ıa a
II26 Procesadores de lenguaje
An´lisis semńtico
a a

Esquema del tema
1. Introducciń
o
2. Esquemas de traducciń dirigidos por la sintaxis
o
3. El ´rbol de sintaxis abstracta
a
4. Comprobaciones semńticas
a
5. Interpretaciń
o
6. Introducciń a metacomp
o
7. Algunas aplicaciones
8. Resumen del tema

1. Introducciń
o
Hay determinadas caracter´ ısticas de los lenguajes de programaciń que no pueden ser mode-
o
ladas mediante gram´ticas incontextuales y que es necesario comprobar en una fase posterior al
a
an´lisis sintćtico. Por otro lado, las fases posteriores de la compilaciń o interpretaciń necesitan
a a o o
una representaciń de la entrada que les permita llevar a cabo sus funciones de manera adecuada.
o
Estas dos vertientes —detecciń de errores y representaciń de la informaciń— estń muy
o o o a
relacionadas y se solapan en la prćtica. Supongamos, por ejemplo, que nuestro lenguaje permite
a
asignaciones segń la regla
u

Asignaciń → id:= Expresiń ;
o o

Es habitual que se impongan ciertas restricciones. En nuestro caso, estas podr´ ser:
ıan

El identificador de la parte izquierda debe estar declarado previamente.
El tipo de la expresiń debe ser compatible con el del identificador.
o

El analizador semńtico deber´ comprobar que estas dos restricciones se cumplen antes de decla-
a a
rar que la sentencia de asignaciń est´ bien formada. Pero sucede que la informaciń necesaria
o a o
para comprobarlas es util tambiń para generar c´digo. Esto quiere decir que si tuvi´ramos una
´ e o e
separaciń estricta entre las fases del compilador, para generar c´digo deber´
o o ıamos volver a mirar
el identificador para saber a qu´ objeto (variable, funciń, constante, etc.) corresponde y qu´ tipo
e o e
tiene y tambiń deber´
e ıamos volver a comprobar los tipos de la expresiń para generar el c´digo
o o
adecuado.
Por otro lado, aunque en teor´ el arbol de an´lisis ser´ suficiente para fases posteriores de la
ıa ´ a ıa
compilaciń o interpretaciń, es una representaciń que contiene mucha informaciń redundante.
o o o o
As´ el ´rbol correspondiente a a:= b+c; bien podr´ tener el aspecto del ´rbol de la izquierda,
ı, a ıa a
cuando el de la derecha contiene esencialmente la misma informaciń y resulta m´s c´modo para
o a o

2 II26 Procesadores de lenguaje

trabajar:
Asignaciń
o

ida := Expresiń
o ;
asignaciń
o
Expresiń
o + T´rmino
e
variablea suma
T´rmino
e Factor
variableb constantec

Factor idc

idb
El segundo ´rbol se conoce como ´rbol de sintaxis abstracta (o AST, de las iniciales en ingl´s).
a a e
Como hemos comentado, durante el an´lisis semńtico se recoge una serie de informaciones que
a a
resultan de utilidad para fases posteriores. Estas informaciones se pueden almacenar en el ´rbol,
a
“decorńdolo”:
a
asignaciń
o

variable suma
nombre: a tipo: entero
tipo: entero

variable constante
nombre: b nombre: c
tipo: entero tipo: entero
valor: 5

As´ el objetivo de la fase de an´lisis semńtico ser´ doble: por un lado detectaremos errores que
ı a a a
no se han detectado en fases previas y por otro lado obtendremos el AST decorado de la entrada.
Para ello utilizaremos esquemas de traducciń dirigidos por la sintaxis, que permitirń asociar
o a
acciones a las reglas de la gram´tica. Estas acciones realizarń comprobaciones y construirń el
a a a
AST que despu´s se recorrer´ para terminar las comprobaciones y ser´ la base para la interpreta-
e a a
ciń o la generaciń de c´digo.
o o o

2. Esquemas de traducciń dirigidos por la sintaxis
o
Nuestro objetivo es especificar una serie de acciones que se realizarń durante el an´lisis de
a a
la entrada y tener un mecanismo que nos permita obtener la informaciń necesaria para realizar
o
estas acciones. Para esto aãdimos a las gram´ticas dos elementos nuevos:
n a
Acciones intercaladas en las reglas.
Atributos asociados a los no terminales de la gram´tica.
a

2.1. Acciones intercaladas en las reglas
Supongamos que tenemos el no terminal A que deriva dos partes diferenciadas y queremos
que se escriba el mensaje “Cambio de parte” tras analizarse la primera. Podemos describir esto

a a 3

de forma sencilla si aumentamos nuestra gram´tica incluyendo la acciń en la parte derecha de la
a o
regla de A :

A → Parte1 {escribe(“Cambio de parte”);} Parte2

Podemos entender esta regla extendida como la receta: “analiza la primera parte, una vez
encontrada, escribe el mensaje y despu´s analiza la segunda parte”.
e

2.2. Atributos asociados a los no terminales
Si nuestras acciones se limitaran a escribir mensajes que indicaran la fase del an´lisis en la que
a
nos encontramos, no necesitar´ ıamos mucho m´s. En general, querremos que las acciones respondan
a
al contenido de los programas que escribimos. Para ello, vamos a aãdir a los no terminales una serie
n
de atributos. Estos no son m´s que una generalizaciń de los atributos que tienen los terminales.
a o
Vamos a ver un ejemplo.
Supongamos que en un lenguaje de programaciń se exige que en las subrutinas aparezca un
o
identificador en la cabecera que debe coincidir con el que aparece al final. Tenemos el siguiente
fragmento de la gram´tica del lenguaje:
a

Subrutina → Cabecera Cuerpo Fin
Cabecera → subrutina id( Par´metros );
a
Fin → fin id

En la regla correspondiente a Fin querremos comprobar que el identificador es el mismo que
en la cabecera. Vamos a definir un atributo del no terminal Fin que ser´ el que nos diga el nombre
a
de la funciń:
o

Fin → fin id {si id.lexema = Fin .nombre entonces error fin si}

El atributo nombre es lo que se conoce como un atributo heredado: su valor se calcular´ en las
a
reglas en las que Fin aparezca en la parte derecha y se podr´ utilizar en las reglas en las que Fin
a
aparezca en la izquierda; ser´ informaciń que “heredar´” de su entorno. F´
a o a ıjate en c´mo hemos
o
empleado un atributo de id para hacer comprobaciones. El analizador semńtico es el que emplea
a
la informaciń contenida en los atributos de los componentes l´xicos. Recuerda que el sintćtico
o e a
s´lo ve las etiquetas de las categor´ En cuanto a error, suponemos que representa las acciones
o ıas.
necesarias para tratar el error.
Ahora tenemos que completar las acciones de modo que Fin tenga algń valor para el nombre.
u
Podemos aãdir una acciń a la regla de Subrutina para calcular el valor de Fin .nombre:
n o

Subrutina → Cabecera Cuerpo { Fin .nombre:= Cabecera .nombre} Fin

Lo que hacemos es copiar el atributo nombre que nos “devolver´” Cabecera . No debes confundir
a
el atributo nombre de Fin con el de Cabecera , son completamente independientes. De hecho, el
atributo nombre de Cabecera es un atributo sintetizado: su valor se calcular´ en las reglas en las
a
que Cabecera aparezca en la parte izquierda y se utilizar´ en las reglas donde Cabecera aparezca
a
en la parte derecha; es informaciń que Cabecera “sintetiza” para su entorno. Debemos calcular
o
el valor de nombre en la regla de Cabecera :

Cabecera → subrutina id( Par´metros ); { Cabecera .nombre:= id.lexema}
a

2.3. Otros elementos de las acciones
Como habr´s comprobado, no hemos definido ningń lenguaje formal para escribir las acciones.
a u
Asumiremos que se emplean construcciones corrientes de los algoritmos tales como condicionales

c Universitat Jaume I 2006-2007


o bucles. Tambiń haremos referencia en ellos a subrutinas y a variables. Las variables las inter-
e
pretaremos como variables locales a la regla que estamos analizando o como variables globales si
lo indicamos expl´
ıcitamente. As´ en:
ı,

Valor → opsum {si opsum.lexema=“+” entonces signo:= 1 si no signo:= -1 fin si}
Valor 1 { Valor .v:= signo* Valor 1 .v}

no hay ninguna “interferencia” entre las distintas variables signo que se puedan utilizar en un mo-
mento dado. F´ ıjate tambiń en c´mo hemos distinguido mediante un sub´
e o ındice las dos apariciones
del no terminal Valor .
Un recurso muy util son los atributos que contienen listas. Por ejemplo, para una declaraciń
´ o
de variables del tipo:

DeclVariables → ListaIds : Tipo
ListaIds → id, ListaIds |id

podemos hacer lo siguiente:

DeclVariables → ListaIds : Tipo
{para v en ListaIds .l hacer: declara_var(v, Tipo .t) fin para}
ListaIds → id, ListaIds 1 { ListaIds .l:= concat( [id.lexema], ListaIds 1 .l)}
ListaIds → id { ListaIds .l:= [id.lexema]}

2.4. Recopilaciń
o
Con lo que hemos visto, podemos decir que un esquema de traducciń consta de:
o

Una gram´tica incontextual que le sirve de soporte.
a
Un conjunto de atributos asociados a los s´
ımbolos terminales y no terminales.
Un conjunto de acciones asociadas a las partes derechas de las reglas.

Dividimos los atributos en dos grupos:

Atributos heredados.
Atributos sintetizados.

Sea A → X1 . . . Xn una producciń de nuestra gram´tica. Exigiremos que:
o a

Las acciones de la regla calculen todos los atributos sintetizados de A .
Las acciones situadas a la izquierda de Xi calculen todos los atributos heredados de Xi .
Ninguna acciń haga referencia a los atributos sintetizados de los no terminales situados a
o
su derecha en la producciń.
o

Las dos ultimas reglas nos permitirń integrar las acciones semńticas en los analizadores descen-
´ a a
dentes recursivos. Cuando se emplean, se dice que el esquema de traducciń est´ basado en una
o a
gram´tica L-atribuida. La L indica que el an´lisis y evaluaciń de los atributos se pueden hacer de
a a o
izquierda a derecha.

a a 5

Ejercicio 1
Las siguientes reglas representan parte de las sentencias estructuradas de un lenguaje de pro-
gramaciń:
o

Programa → Sentencias
Sentencias → Sentencia Sentencias | Sentencia
Sentencia → mientras Expresiń hacer Sentencias finmientras
o
Sentencia → si Expresiń entonces Sentencias sino Sentencias finsi
o
Sentencia → interrumpir
Sentencia → otros

Aãde las reglas necesarias para comprobar que la instrucciń interrumpir aparece unicamente
n o ´
dentro de un bucle.

Ejercicio 2
Sea G la siguiente gram´tica:
a

A → B C |a
B → A a B b| C a
C → a C C |aba C |a

Aãde a G las reglas semńticas necesarias para que el atributo ia de A contenga el n´mero
n a u
de aes al inicio de la cadena generada. Por ejemplo, dadas las cadenas aaaaba, abaaaa y aaa, los
valores de ia ser´ 4, 1 y 3, respectivamente.
ıan
Puedes utilizar los atributos adicionales que consideres necesarios, pero ninguna variable global.
Adem´s, los atributos que aãdas deben ser de tipo entero o l´gico.
a n o

2.5. Algunas cuestiones formales
Una pregunta razonable es si puede el s´ ımbolo inicial tener atributos heredados y, si esto es
as´ de dńde proceden. La respuesta var´ segń los textos. Los que se oponen, defienden que el
ı, o ıa u
significado del programa debe depender unicamente de ´l. Los que estń a favor de los atributos
´ e a
heredados, sostienen que permiten formalizar la entrada de informaciń acerca de, por ejemplo, el
o
entorno donde se ejecutar´ el programa o las opciones de compilaciń.
a o
Una situaciń similar se da con los s´
o ımbolos terminales: hay autores que piensan que no deber´ıan
tener atributos en absoluto; otros defienden que s´lo deben tener atributos sintetizados; y los hay
o
que opinan que pueden tener tanto atributos heredados como sintetizados.
Otro aspecto sobre el que hay diferencias de interpretaciń es el de los efectos laterales de las
o
reglas. En algunos textos, las reglas de evaluaciń de los atributos no pueden tener efectos laterales.
o
Otros autores defienden que esta distinciń no es m´s que un problema de implementaciń ya que
o a o
es posible aãdir un nuevo atributo que represente el entorno e ir actualizńdolo adecuadamente.
n a
Esto unicamente supone una incomodidad, pero no un problema formal. Esta es la posiciń que
´ o
seguiremos nosotros, permitiendo que haya efectos laterales en el c´lculo de atributos.
a
Quiz´ los ejemplos m´s claros de existencia de efectos laterales sean el manejo de la tabla de
a a
s´
ımbolos y el control de errores. Cuando se encuentra una declaraciń en un programa es necesario
o
actualizar la tabla de s´ ımbolos de modo que sea posible reconocer ocurrencias posteriores del
identificador. Podemos suponer que existe una tabla de s´ ımbolos global o tener un atributo que
lleve copias de la tabla de un sitio a otro.
Por otro lado, en caso de que se encuentre un error, es necesario tomar medidas como detener
la generaciń de c´digo. Una manera sencilla de marcar esta circunstancia es tener una variable
o o



global de tipo l´gico que indique si se ha encontrado algń error. Nuevamente, ser´ posible, pero
o u ıa
no necesario, tener un atributo que transporte esa informaciń.
o
2.6. Eliminaciń de recursividad por la izquierda y atributos
o
En el tema de an´lisis sintćtico vimos c´mo se pueden modificar las producciones con recursivi-
a a o
dad por la izquierda para lograr que la gram´tica sea LL(1). El problema con las transformaciones
a
es que dejan una gram´tica que tiene muy poca relaciń con la original, lo que hace que escribir los
a o
atributos y las reglas correspondientes sea dif´ sobre la gram´tica transformada. Sin embargo,
ıcil a
se pueden escribir los atributos sobre la gram´tica original y despu´s convertirlos de una manera
a e
bastante mecńica.
a
Como las GPDRs no suelen necesitar recursividad por la izquierda, es fćil que no tengas que
a
utilizar esta transformaciń. Pese a todo, vamos a ver c´mo se hace la transformaciń sobre un
o o o
ejemplo. Partimos del siguiente esquema de traducciń:o

E → E 1 + T { E .v:= E 1 .v+ T .v}
E → T { E .v:= T .v}
T → num { T .v:= num.v}

Comenzamos por transformar la gram´tica:
a

E → T E’
E’ → + T E’
E’ → λ
T → num

Como vemos, el problema es que cuando vemos el sumando derecho en E’ , no tenemos acceso
al izquierdo. La idea ser´ crear un atributo heredado que nos diga el valor del sumando izquierdo.
a
En la primera regla lo podemos calcular directamente. En la segunda regla, realizamos la suma y
la transmitimos:

E → T { E’ .h:= T .v} E’
E’ → + T { E’ 1 .h:= E’ .h+ T .v} E’ 1

Con esto, el atributo h contendr´ siempre la suma, que es el valor que tenemos que devolver
a
finalmente. Por eso hay que “transmitir” el nuevo valor al atributo v:

E → T { E’ .h:= T .v } E’ { E .v:= E’ .v}
E’ → + T { E’ 1 .h:= E’ .h+ T .v} E’ 1 { E’ .v:= E’ 1 .v}

¿Qu´ hacemos cuando E’ se reescribe como la cadena vac´ En este caso, basta con devolver
e ıa?
como sintetizado el valor que se hereda. El esquema de traducciń completo queda:
o

E → T { E’ .h:= T .v} E’ { E .v:= E’ .v}
E’ → + T { E’ 1 .h:= E’ .h+ T .v} E’ 1 { E’ .v:= E’ 1 .v}
E’ → λ { E’ .v:= E’ .h}
T → num { T .v:= num.v}

Ejercicio 3
Escribe el ´rbol de an´lisis de 3+4 con el esquema original y el transformado. Dec´ralos.
a a o

a a 7

Ejercicio 4
Transforma el siguiente esquema de traducciń para eliminar la recursividad por la izquierda:
o

E → E 1 + T { E .v:= E 1 .v+ T .v}
E → T { E .v:= T .v}
T → T 1 * F { T .v:= T 1 .v* F .v}
T → F { T .v:= F .v}
F → ( E ) { F .v:= E .v}
F → num { F .v:= num.v}

El siguiente ejercicio presenta la transformaciń de una manera m´s general.
o a
Ejercicio* 5
Si tenemos las siguientes reglas en un esquema de traducciń
o

A → A 1 Y { A .a:= g( A 1 .a, Y .y)}
A → X { A .a:= f( X .x)}

podemos transformarlas en

A → X { A’ .h:= f( X .x)} A’ { A .a:= A’ .s}
A’ → Y { A’ 1 .h:= g( A’ .h, Y .y)} A’ 1 { A’ .s:= A’ 1 .s}
A’ → λ { A’ .s:= A’ .h}

Comprueba que la transformaciń es correcta analizando X Y 1 Y 2 mediante las dos versiones y
o
comparando el valor de a.

2.7. Implementaciń de los esquemas de traducciń
o o
La interpretaciń de las acciones como sentencias que se ejecutan al pasar el an´lisis por ellas
o a
permite implementar los esquemas de traducciń de manera sencilla. Para ello se modifica la
o
implementaciń del analizador recursivo descendente correspondiente a la gram´tica original de la
o a
siguiente manera:
Los atributos heredados del no terminal A se interpretan como par´metros de entrada de
a
la funciń Analiza_A.
o
Los atributos sintetizados del no terminal A se interpretan como par´metros de salida de
a
la funciń Analiza_A.
o
Las acciones semńticas, una vez traducidas al lenguaje de programaciń correspondiente, se
a o
insertan en la posiciń correspondiente segń su orden en la parte derecha donde aparecen.
o u
En la prćtica, es frecuente que, si el lenguaje de programaciń (como C) no permite devolver
a o
m´s de un valor, los atributos sintetizados del no terminal se pasen por referencia.
a
En Python existe una soluciń bastante c´moda. Comenzamos por definir una clase vac´
o o ıa:
class Atributos:
pass
Antes de llamar a una funciń o m´todo de an´lisis, creamos un objeto de esta clase y le
o e a
aãdimos los atributos heredados del no terminal. La correspondiente funciń de an´lisis crear´
n o a a
los atributos sintetizados. Este es el unico par´metro que se pasa. As´ la traducciń de la regla:
´ a ı, o



E → T { R .h:= T .v} R { E .v:= R .v}

es la siguiente:

def analiza_E(E):
T= Atributos() # Atributos de T
R= Atributos() # Atributos de R
analiza_T(T)
R.h= T.v # Creamos un atributo heredado de R
analiza_R(R)
E.v= R.v # Creamos un atributo sintetizado de E

L´gicamente, tendr´
o ıamos que haber aãdido el c´digo de control de errores.
n o

2.8. Atributos en GPDR
La interpretaciń que hemos hecho de los esquemas de traducciń se traslada de forma natural
o o
a las GPDR. Por ejemplo, la traducciń de:
o

E → T 1 { E .v:= T 1 .v}(+ T 2 { E .v:= E .v+ T 2 .v})∗

es simplemente:

def analiza_E(E):
T1= Atributos() # Atributos de T1
T2= Atributos() # Atributos de T2
analiza_T(T1)
E.v= T1.v
while token.cat=="suma":
token= alex.siguiente()
analiza_T(T2)
E.v= E.v+T2.v

Como antes, habr´ que aãdir el correspondiente c´digo para controlar errores.
ıa n o

3. El ´rbol de sintaxis abstracta
a
Como hemos comentado en la introducciń, una de las posibles representaciones semńticas de
o a
la entrada es el ´rbol de sintaxis abstracta o AST.
a
Aunque es similar a los ´rboles de an´lisis sintćtico, tiene algunas diferencias importantes:
a a a

No aparecen todos los componentes l´xicos del programa. Por ejemplo:
e

• No es necesario incluir los parńtesis de las expresiones.
e
• No se necesitan los separadores o terminadores de las sentencias.
• ...

Pueden aparecer otros componentes no estrictamente sintćticos, como acciones de coerciń
a o
de tipos.

a a 9

3.1. Construcciń
o
Para construir los ´rboles, debemos comenzar por definir qu´ elementos emplearemos para cada
a e
estructura:

Estructura Representaciń
o Estructura Representaciń
o
si sentencias
if E then LS end begin S 1 . . . S n end
E LS S 1 ... Sn
mientras asignaciń
o
while C do LS end id:= E ;
C LS id E
repetir suma
repeat LS until C ; E 1+ E 2
LS C E1 E2
... ... ... ...

F´
ıjate que el ´rbol resultante puede representar programas en diversos lenguajes de programa-
a
ciń del estilo C, Pascal, etc.
o
Ahora debemos utilizar los atributos para construir el ´rbol. Utilizando el atributo arb para
a
devolver el ´rbol que construye cada no terminal, podemos hacer algo parecido a:
a
Sentencia → if Expresiń then Sentencias end
o
{ Sentencia .arb:= NodoSi( Expresiń .arb, Sentencias .arb)}
o
Sentencia → while Expresiń do Sentencias end
o
{ Sentencia .arb:= NodoMientras( Expresiń .arb, Sentencias .arb)}
o
Sentencia → repeat Sentencias until Expresiń ;
o
{ Sentencia .arb:= NodoRepetir( Sentencias .arb, Expresiń .arb)}
o
Sentencia → id:= Expresiń ;
o
{ Sentencia .arb:= NodoAsignaciń(id.lexema, Expresiń .arb)}
o o
Para la implementaciń hay dos opciones principales:
o
Utilizar funciones (NodoSi, NodoMientras, . . . ) que devuelvan una estructura de datos ade-
cuada.
Utilizar objetos (NodoSi, NodoMientras, . . . ) para cada uno de los nodos.
Probablemente, la segunda opciń sea la m´s c´moda para el trabajo posterior con el ´rbol.
o a o a
En cuanto a la lista de sentencias, podemos utilizar nodos que tengan un grado variable, para
eso almacenamos una lista con los hijos:
Sentencias → {l:=λ} ( Sentencia {l:=l+ Sentencia .arb})∗
{ Sentencias .arb:= NodoSentencias(l)}

El tratamiento de las expresiones es sencillo. Por ejemplo, para la suma podemos hacer:
Expresiń
o → T´rmino 1 {arb:= T´rmino 1 .arb}
e e
( + T´rmino 2 {arb:=NodoSuma(arb, T´rmino 2 .arb)})∗
e e
{ Expresiń .arb:= arb}
o



Las restas, productos, etc, se tratar´ de forma similar. Puedes comprobar que de esta manera
ıan
el AST resultante respeta la asociatividad por la izquierda.
Ejercicio* 6

En el caso de la asociatividad por la derecha tenemos dos opciones: crear una lista de operandos
y recorrerla en orden inverso para construir el ´rbol o utilizar recursividad por la derecha, que
a
no da problemas para el an´lisis LL(1). Utiliza ambas posibilidades para escribir sendos esque-
a
mas de traducciń que construyan los AST para expresiones formadas por sumas y potencias de
o
identificadores siguiendo las reglas habituales de prioridad y asociatividad.

3.2. Evaluaciń de atributos sobre el AST
o

Un aspecto interesante del AST es que se puede utilizar para evaluar los atributos sobre ´l, ene
lugar de sobre la gram´tica inicial. Si reflexionas sobre ello, es l´gico. Todo el proceso de evaluaciń
a o o
de los atributos se puede ver como el etiquetado de un ´rbol (el ´rbol de an´lisis), pero no hay
a a a
nada que impida que el ´rbol sobre el que se realiza la evaluaciń sea el AST.
a o
Un ejemplo ser´ el c´lculo de tipos. Si tenemos la expresiń (2+3.5)*4, podemos calcular los
ıa a o
tipos sobre el ´rbol de an´lisis:
a a

Expresiń
o
t: real

T´rmino
e
t: real

Factor * Factor
t: real t: entero

( Expresiń
o ) num
t: real v: 4
t: entero

T´rmino
e + T´rmino
e
t: entero t: real

Factor Factor
t: entero t: real

num num
v: 2 v: 3.5
t: entero t: real

a a 11

o ıamos utilizar una gram´tica similar a la siguiente1 :
Para realizar esta evaluaciń, podr´ a

Expresiń
o → T´rmino 1 {t:= T´rmino 1 .t}(+ T´rmino 2 {t:= m´sgeneral(t, T´rmino 2 .t)})∗
e e e a e
{ Expresiń .t:= t}
o
...
T´rmino
e → Factor 1 {t:= Factor 1 .t}(* Factor 2 {t:= m´sgeneral(t, Factor 2 .t)})∗
a
{ T´rmino .t:= t}
e
...
Factor → num { Factor .t:= num.t}
Factor → ( Expresiń ) { Factor .t:= Expresiń .t}
o o
...

Tambiń podemos realizar el c´lculo sobre el AST:
e a

producto
t: real

suma num
t: real v: 4
t: entero

num num
v: 2 v: 3.5
t: entero t: real

Esto se har´ junto con el resto de comprobaciones semńticas.
ıa a
La elecciń acerca de si evaluar atributos en el AST o durante el an´lisis descendente es b´si-
o a a
camente una cuestiń de simplicidad. Generalmente, podemos decir que los atributos sintetizados
o
tienen una dificultad similar en ambos casos. Sin embargo, cuando la gram´tica ha sufrido trans-
a
formaciones o hay muchos atributos heredados, suele ser m´s fćil evaluarlos sobre el AST.
a a
Otro aspecto interesante a la hora de decidir qu´ atributos evaluar sobre el ´rbol de an´lisis y
e a a
cu´les sobre el AST est´ en los propios nodos del ´rbol. Supongamos que queremos tener nodos
a a a
diferentes para la suma entera y la suma real. En este caso, tendremos que comprobar los tipos
directamente sobre el ´rbol de an´lisis (o crear un AST y despu´s modificarlo, pero esto puede ser
a a e
forzarlo demasiado).

4. Comprobaciones semńticas
a
Los atributos nos permitirń llevar a cabo las comprobaciones semńticas que necesite el len-
a a
guaje. En algunos casos, utilizaremos los atributos directamente (posiblemente evaluados sobre el
AST), por ejemplo en la comprobaciń que hac´
o ıamos de que el identificador al final de la funciń
o
era el mismo que al principio.
En otros casos, los atributos se utilizan indirectamente mediante estructuras globales, por
ejemplo la tabla de s´
ımbolos. Un ejemplo ser´ la comprobaciń de que un identificador no se ha
ıa o
declarado dos veces. Si hemos utilizado un nodo similar a:
1 Utilizamos la funciń m´sgeneral que devuelve el tipo m´s general de los que se le pasan como par´metros (el
o a a a
tipo real se considera m´s general que el entero).
a



declaraciń
o

Tipo Listaids

el m´todo de comprobaciń ser´
e o ıa:
Objeto NodoDeclaraciń: o
...
M´todo compsemńticas()
e a
...
para i ∈ listaids hacer
si TablaS´ımbolos.existe(i) entonces
error
si no
TablaS´ ımbolos.inserta(i, tipo)
fin si
fin para
...
fin compsemńticas
a
...
fin NodoDeclaracińo
Utilizando directamente el esquema de traducciń habr´ que duplicar parte del c´digo:
o ıa o

Declaraciń
o → Tipo { Listaids .t:= Tipo .t } Listaids
Listaids → id, { Listaids 1 .t:= Listaids .t} Listaids 1
{si TablaS´
ımbolos.existe(id.lexema)
entonces error
si no TablaS´
ımbolos.inserta(id.lexema, Listaids .t)}
Listaids → id
{si TablaS´
ımbolos.existe(id.lexema)
entonces error
si no TablaS´
ımbolos.inserta(id.lexema, Listaids .t)}

4.1. La tabla de s´
ımbolos
Durante la construcciń del AST, las comprobaciones semńticas y, probablemente, durante la
o a
interpretaciń y la generaciń de c´digo necesitaremos obtener informaciń asociada a los distintos
o o o o
identificadores presentes en el programa. La estructura de datos que permite almacenar y recuperar
esta informaciń es la tabla de s´
o ımbolos.
En principio, la tabla debe ofrecer operaciones para:

Insertar informaciń relativa a un identificador.
o
Recuperar la informaciń a partir del identificador.
o

La estructura que puede realizar estas operaciones de manera eficiente es la tabla hash (que
en Python est´ disponible mediante los diccionarios). La implementaciń habitual es una tabla
a o
que asocia cada identificador a informaciń tal como su naturaleza (constante, variable, nombre de
o
funciń, etc.), su tipo (entero, real, booleano, etc.), su valor (en el caso de constantes), su direcciń
o o
(en el caso de variables y funciones), etc.
Es importante tener unicamente una tabla; si tenemos varias, por ejemplo, una para constantes
´
y otra para variables, el acceso se hace m´s dif´ ya que para comprobar las propiedades de un
a ıcil
identificador hay que hacer varias consultas en lugar de una.

a a 13

Una cuestiń importante es c´mo se relacionan la tabla y el AST. Tenemos distintas posibili-
o o
dades, que explicaremos sobre el siguiente ´rbol, correspondiente a la sentencia a= a+c:
a
asignaciń
o

variable suma

variable variable
nombre: a nombre: c

La primera posibilidad es dejar el ´rbol tal cual y cada vez que necesitemos alguna informaciń,
a o
por ejemplo el valor de a, consultar la tabla. Esta opciń ser´ la m´s adecuada para situaciones
o ıa a
en las que se vaya a recorrer el ´rbol pocas veces, por ejemplo en una calculadora donde se evalé
a u
cada expresiń una sola vez.
o
Otra posibilidad es ir decorando cada una de las hojas con toda la informaciń que se vaya
o
recopilando. Por ejemplo, si durante el an´lisis averiguamos el tipo y direcciń de las variables,
a o
pasar´ıamos a almacenar la nueva informaciń: o
Tabla de s´
ımbolos

asignaciń
o a: {tipo:entero, dir:1000}
...

variable suma c: {tipo:entero, dir:1008}
tipo: entero ...
dir: 1000
variable variable
nombre: a nombre: c
tipo: entero tipo: entero
dir: 1000 dir: 1008

Esto tiene costes muy elevados en tiempo —tendremos que actualizar repetidamente un n´mero
u
de nodos que puede ser elevado— y espacio —hay mucha informaciń que se almacena repetida—.
o
Podemos reducir estos costes guardando en cada nodo un puntero a la entrada correspondiente en
la tabla:
Tabla de s´
ımbolos
a: {tipo:entero, dir:1000}
asignaciń
o ...

c: {tipo:entero, dir:1008}
variable suma
...
tipo: entero

variable variable

Finalmente, la opciń m´s adecuada cuando tenemos lenguajes que presenten ´mbitos anidados
o a a
(veremos en otro tema c´mo representar los ´mbitos en la tabla) es guardar la informaciń sobre
o a o



los objetos en otra estructura de datos a la que apunta tanto la tabla como los nodos del ´rbol:
a
Informaciń objetos
o
{tipo:entero, dir:1000}
asignaciń
o ...

{tipo:entero, dir:1008}
variable suma
...
tipo: entero

Tabla de s´
ımbolos
variable variable
a
c
...

4.2. Comprobaciones de tipos
Un aspecto importante del an´lisis semńtico es la comprobaciń de los tipos de las expresiones.
a a o
Esta comprobaciń se hace con un doble objetivo:
o
Detectar posibles errores.
Averiguar el operador o funciń correcto en casos de sobrecarga y polimorfismo.
o
Para representar los tipos en el compilador, se emplean lo que se denominan expresiones de
tipo (ET). La definiciń de estas expresiones es generalmente recursiva. Un ejemplo ser´
o ıa:
Los tipos b´sicos: real, entero,. . . , adem´s de los tipos especiales error de tipo y ausencia de
a a
tipo (void) son ETs.
Si n1 y n2 son enteros, rango(n1 , n2 ) es una ET.
Si T es una ET, tambiń lo es puntero(T ).
e
Si T1 y T2 son ETs, tambiń lo es T1 → T2 .
e
Si T1 y T2 son ETs, tambiń lo es vector(T1 , T2 ).
e
Si T1 y T2 son ETs, tambiń lo es T1 × T2 .
e
Si T1 ,. . . ,Tk son ETs y N1 ,. . . ,Nk son nombres de campos, registro((N1 , T1 ), . . . , (Nk , Tk ))
es una ET.
Ten en cuenta que segń los lenguajes, estas definiciones cambian. Es m´s, los lenguajes pueden
u a
restringir qu´ expresiones realmente resultan en tipos v´lidos para los programas (por ejemplo, en
e a
Pascal no se puede definir un vector de funciones).
Algunos ejemplos de declaraciones y sus expresiones correspondientes ser´ ıan:

Declaraciń
o Expresiń de tipo
o
int v[10]; vector(rango(0, 9),entero)
struct { registro((a,entero), (b,real))
int a;
float b;
} st;
int *p; puntero(entero)
int f(int, char); entero × carćter → entero
a
void f2(float); real → void

a a 15

4.2.1. Equivalencia de tipos
Comprobar si dos expresiones de tipo, T1 y T2 , son equivalentes es muy sencillo. Si ambas
corresponden a tipos elementales, son equivalentes si son iguales. En caso de que correspondan a
tipos estructurados, hay que comprobar si son el mismo tipo y si los componentes son equivalentes.
En muchos lenguajes se permite dar nombre a los tipos. Esto introduce una sutileza a la hora
de comprobar la equivalencia. La cuestiń es, dada una declaraciń como
o o

typedef int a;
typedef int b;

¿son equivalentes a y b? La respuesta depende del lenguaje (o, en casos como el Pascal, de la
implementaciń). Existen dos criterios para la equivalencia:
o

Equivalencia de nombre: dos expresiones de tipo con nombre son equivalentes si y s´lo si tienen
o
el mismo nombre.
Equivalencia estructural: dos expresiones de tipo son equivalentes si y s´lo si tienen la misma
o
estructura.

Hay argumentos a favor de uno y otro criterio. En cualquier caso, hay que tener en cuenta que
para comprobar la equivalencia estructural ya no sirve el m´todo trivial presentado antes. En este
e
caso, puede haber ciclos, lo que obliga a utilizar algoritmos m´s complicados.
a

4.2.2. Comprobaciń de tipos en expresiones
o
Para comprobar los tipos en las expresiones podemos utilizar un atributo que indique el tipo
de la expresiń. Este tipo se infiere a partir de los distintos componentes de la expresiń y de las
o o
reglas de tipos del lenguaje.
A la hora de calcular el tipo hay varias opciones: podemos calcularlo sobre la gram´tica, sobre
a
el AST o al construir el AST. En cualquier caso, puede ser util tener una funciń similar a la de
´ o
la secciń 3.2 que refleje las peculiaridades de los tipos del lenguaje. Por ejemplo, si tenemos tipos
o
entero y real con las reglas habituales de promociń, esta funciń devolver´ los resultados segń
o o ıa u
esta tabla:

Primero Segundo Resultado
entero entero entero
entero real real
real entero real
real real real
otros error tipo

El c´lculo de atributos de tipo deber´ ser trivial sobre la gram´tica o sobre el AST. En cuanto
a ıa a
al c´lculo al construir el AST, se puede, por ejemplo, hacer que el constructor compruebe los tipos
a
de los componentes que recibe. En este caso, si es necesario, se puede aãdir un nodo de promociń
n o
de tipos. Por ejemplo, si vamos a crear un nodo suma a partir de los ´rboles:
a

producto suma
t: entero t: real

y ,
variable num variable num
t: entero t: entero t: real t: real
nombre: a valor: 3 nombre: z valor: 3.14

podemos aãdir un nodo intermedio para indicar la promociń:
n o



suma
t: real

enteroAreal suma
t: real

producto
t: entero variable num
t: real t: real
nombre: z valor: 3.14
variable num
t: entero t: entero
nombre: a valor: 3

Respecto a la propagaciń de los errores de tipo, hay que intentar evitar un exceso de mensajes
o
de error. Para ello se pueden utilizar distintas estrategias:
Se puede hacer que error tipo sea compatible con cualquier otro tipo.
Se puede intentar inferir cu´l ser´ el tipo en caso de no haber error. Por ejemplo: si el
a ıa
operador en que se ha detectado el error es el y-l´gico, se puede devolver como tipo el tipo
o
l´gico.
o

5. Interpretaciń
o
La utilizaciń del AST hace que la interpretaciń sea bastante sencilla. Una vez lo hemos
o o
construido, tenemos dos aproximaciones para la interpretaciń:
o
Podemos representar la entrada mediante una serie de instrucciones similares a un lenguaje
m´quina con algunas caracter´
a ısticas de alto nivel. Este es el caso, por ejemplo, de Java y el
Java bytecode. Esta aproximaciń representa prćticamente una compilaciń.
o a o
La otra alternativa es representar la entrada de manera similar al AST y recorrerlo para
ejecutar el programa.
Utilizaremos la segunda opciń. Los nodos correspondientes a las expresiones tendrń un m´-
o a e
todo al que llamaremos evalá y que devolver´ el resultado de evaluar el sub´rbol correspondiente.
u a a
Por ejemplo, en el nodo de la suma tendr´ ıamos:
Objeto NodoSuma:
...
M´todo evalá()
e u
devuelve i.evalá() + d.evalá(); // i y d son los hijos del nodo
u u
fin evalá
u
...
fin NodoSuma
Aquellos nodos que representen sentencias tendrń el m´todo interpreta. Por ejemplo, para un
a e
nodo que represente un mientras, el m´todo correspondiente ser´
e ıa:
Objeto NodoMientras:
...
M´todo interpreta()
e
mientras condiciń.evalá()=cierto:
o u
sentencias.interpreta()
fin mientras
fin interpreta
...
fin NodoMientras

a a 17

Las variables se representar´ mediante entradas en una tabla (que, en casos sencillos, puede
ıan
ser la tabla de s´
ımbolos) que contenga el valor correspondiente en cada momento. Una asignaciń o
consiste simplemente en evaluar la expresiń correspondiente y cambiar la entrada de la tabla.
o
La ejecuciń del programa consistir´ en una llamada al m´todo interpreta del nodo ra´ del
o a e ız
programa. Alternativamente, si hemos guardado el programa como una lista de sentencias, la
ejecuciń consistir´ en un bucle que recorra la lista haciendo las llamadas correspondientes.
o a
L´gicamente, existen otras maneras de recorrer el ´rbol. En particular, si no lo hemos represen-
o a
tado con objetos, podemos recorrerlo mediante funciones recursivas o de manera iterativa. En este
ultimo caso, podemos emplear una pila auxiliar o ir “enhebrando” el ´rbol durante su construcciń.
´ a o
Esta es probablemente la opciń m´s r´pida con una implementaciń cuidadosa, pero es tambiń
o a a o e
la que m´s esfuerzo exige (especialmente si hay que recorrer el ´rbol en distintos ´rdenes).
a a o

6. Introducciń a metacomp
o
Mediante metacomp se pueden traducir esquemas de traducciń a programas Python que im-
o
plementan los correspondientes analizadores descendentes recursivos.
Un programa metacomp se divide en varias secciones. Cada secciń se separa de la siguiente
o
por un carćter “ %” que ocupa la primera posiciń de una l´
a o ınea. La primera secciń contiene la
o
especificaciń del analizador l´xico. Las secciones pares contienen c´digo de usuario. La tercera y
o e o
sucesivas secciones impares contienen el esquema de traducciń. Es decir, un programa metacomp
o
se escribe en un fichero de texto siguiendo este formato:
Especificaciń l´xica
o e
%
C´digo de usuario
o
%
Esquema de traduccińo
%
C´digo de usuario
o
%
Esquema de traduccińo
.
.
.
Las secciones de “c´digo de usuario” se utilizan para declarar estructuras de datos y variables,
o
definir funciones e importar m´dulos utiles para el procesador de lenguaje que estamos especifican-
o ´
do. Estos elementos deberń codificarse en Python. La herramienta metacomp copia literalmente
a
estos fragmentos de c´digo en el programa que produce como salida.
o

6.1. Especificaciń l´xica
o e
La especificaciń l´xica consiste en una serie de l´
o e ıneas con tres partes cada una:

Un nombre de categor´ o la palabra None si la categor´ se omite.
ıa ıa
Un nombre de funciń de tratamiento o None si no es necesario ningń tratamiento.
o u
Una expresiń regular.
o

Los analizadores l´xicos generados por metacomp dividen la entrada siguiendo la estrategia
e
avariciosa y, en caso de conflicto, prefiriendo las categor´ que aparecen en primer lugar. Por
ıas
cada lexema encontrado en la entrada se llama a la correspondiente funciń de tratamiento, que
o
normalmente se limita a calcular algń atributo adicional a los tres que tienen por defecto todos
u
los componentes: lexema, nlinea y cat, que representan, respectivamente, el lexema, el n´mero de
u
l´
ınea y la etiqueta de categor´ del componente.
ıa



Un ejemplo de especificaciń l´xica para una calculadora sencilla ser´
o e ıa:
categor´
ıa expresiń regular
o acciones atributos
+
num [0–9] calcular valor valor
emitir
sum [-+] copiar lexema lexema
emitir
abre ( emitir
cierra ) emitir
espacio [ t]+ omitir
nl n emitir

En metacomp, lo podemos escribir as´
ı:
num valor [0-9]+
sum None [-+]
abre None (
cierra None )
None None [ t]+
nl None n
Donde valor ser´ una funciń como la siguiente:
ıa o
def valor(componente):
componente.v= int(componente.lexema)
No necesitamos ningń tratamiento para sum ya que metacomp aãde por defecto el atributo lexema
u n
(que es el que hemos usado para calcular el valor de los enteros).

6.2. Esquema de traducciń
o
Las secciones de esquema de traducciń contienen las reglas de la GPDR utilizando una sintaxis
o
muy similar a la de la asignatura. Cada regla tiene una parte izquierda, un s´ımbolo ->, una parte
derecha y un punto y coma. Los no terminales se escriben marcados mediante < y >. Los terminales
tienen que coincidir con los declarados en la especificaciń l´xica2 . Se pueden emplear los opera-
o e
dores regulares de concatenaciń (impl´
o ıcita), disyunciń (mediante |), opcionalidad (mediante ?),
o
clausura (mediante *) y clausura positiva (mediante +). Por ejemplo, la regla
E → T (sum T )∗
se escribir´ en metacomp as´
ıa ı:
<E> -> <T> ( sum <T> )*;
Las acciones de las reglas se escriben encerradas entre arrobas (@) y sin fin de l´ ınea entre
ellas. Para poder referirse a los terminales y no terminales, estos estń numerados por su orden
a
de apariciń en la parte derecha de la regla. El no terminal de la izquierda no tiene n´mero y,
o u
si no hay ambigëdad, la primera apariciń de cada s´
u o ımbolo no necesita n´mero. Si tenemos las
u
acciones de la regla anterior:
E → T 1 {v:= T 1 .v}
(sum T 2 {si sum.lexema= “+” entonces v:= v+ T 2 .v si no v:= v− T 2 .v fin si})∗
{ E .v:= v}
podemos escribirlas en metacomp as´
ı:
2 Existe tambiń la posibilidad de utilizar una sintaxis especial para categor´
e ıas con un s´lo lexema, pero no lo
o
comentaremos.

a a 19

<E> -> <T> @v= T.v@
( sum <T>
@if sum.lexema=="+":@
@ v+= T2.v@
@else:@
@ v-= T2.v@
)*
@E.v= v@;

7. Algunas aplicaciones
Vamos a aprovechar metacomp para reescribir los ejemplos que vimos en el tema de an´lisis
a
l´xico: la suma de las columnas de un fichero con campos separados por tabuladores y la lectura
e
de ficheros de configuraciń.
o

7.1. Ficheros organizados por columnas
La representaciń en metacomp de la especificaciń l´xica podr´ ser:
o o e ıa

1 numero valor [0-9]+
2 separacion None t
3 nl None n
4 None None [ ]+

La funciń valor se define en la zona de auxiliares junto con dos funciones para tratamiento
o
de errores:

5 %
6 def valor(componente):
7 componente.v= int(componente.lexema)
8
9 def error(linea, mensaje):
10 sys.stderr.write("Error en lńea %d: %sn" % (linea, mensaje))
ı
11 sys.exit(1)
12
13 def error_lexico(linea, cadena):
14 if len(cadena)> 1:
15 error(linea, "no he podido analizar la cadena %s." % repr(cadena))
16 else:
17 error(linea, "no he podido analizar el carćter %s." % repr(cadena))
a
18
19 ncol= 0

La funciń error la utilizamos para escribir mensajes gen´ricos. La funciń error_lexico es
o e o
llamada por metacomp cuando encuentra un error l´xico. Los dos par´metros que recibe son la
e a
l´
ınea donde se ha producido el error y el carćter o caracteres que no se han podido analizar.
a
Podemos emplear el siguiente esquema de traducciń:o

Fichero → {suma:=0}( L´ ınea .v})∗ { Fichero .suma:= suma}
ınea nl {suma:= suma+ L´
L´
ınea → numero1 {global ncol; col:=1; si col= ncol entonces L´
ınea .v:= numero.v fin si}
(separaciń n´mero2
o u
{col:= col+1; si col= ncol entonces L´
ınea .v:= numero2 .v fin si}
)∗



Hemos supuesto que el s´
ımbolo inicial tiene un atributo sintetizado que leer´ el entorno. Ade-
a
m´s, la columna deseada est´ en la variable global ncol. Representamos esto en metacomp as´
a a ı:

20 %
21 <Fichero>-> @suma= 0@
22 ( <Linea> @suma+= Linea.v@ nl )*
23 @Fichero.suma= suma@ ;
24
25 <Fichero>-> error
26 @error(mc_al.linea(), "lńea mal formada")@
ı
27 ;
28
29 <Linea>-> numero
30 @col= 1@
31 @if col== ncol:@
32 @ Linea.v= numero.v@
33 ( separacion numero
34 @col+= 1@
35 @if col== ncol:@
36 @ Linea.v= numero2.v@
37 )*
38 @if col< ncol:@
39 @ error(numero.nlinea, "no hay suficientes columnas")@
40 ;
41

La regla <Fichero>-> error nos permite capturar los errores que se produzcan durante el an´lisis.
a
Hay varias maneras de tratar los errores, pero hemos optado por abortar el programa. Hemos
utilizado mc_al, que contiene el analizador l´xico, para averiguar el n´mero de l´
e u ınea del error.
Finalmente, hemos decidido que el programa tenga un par´metro que indique qu´ columna
a e
sumar. Si no se especifica ningń par´metro adicional, se leer´ la entrada estńdar. En caso de que
u a a a
haya varios par´metros, se sumar´ la columna deseada de cada uno de los ficheros especificados,
a a
escribińdose el total. Con esto, el programa principal es:
e

42 %
43 def main():
44 global ncol
45 if len(sys.argv)== 1:
46 sys.stderr.write("Error, necesito un n´mero de columna.n")
u
47 sys.exit(1)
48 try:
49 ncol= int(sys.argv[1])
50 except:
51 sys.stderr.write("Error, n´mero de columna mal formado.n")
u
52 sys.exit(1)
53
54 if len(sys.argv)== 2:
55 A= AnalizadorSintactico(sys.stdin)
56 suma= A.Fichero.suma
57 else:
58 suma= 0
59 for arg in sys.argv[2:]:
60 try:
61 f= open(arg)
62 except:

a a 21

63 sys.stderr.write("Error, no he podido abrir el fichero %s.n" % arg)
64 sys.exit(1)
65 A= AnalizadorSintactico(f)
66 suma+= A.Fichero.suma
67 print "La suma es %d." % suma

Por defecto, metacomp genera una funciń main que analiza sys.stdin. Si queremos modificar ese
o
comportamiento, debemos crear nuestra propia funciń. Como ves, la mayor parte del c´digo se
o o
dedica a analizar posibles errores en los par´metros. La construcciń m´s interesante est´ en las
a o a a
dos l´
ıneas que crean el analizador. La asignaciń
o
A= AnalizadorSintactico(f)
hace que se cree un analizador que inmediatamente analizar´ el fichero f (que debe estar abierto).
a
Cuando termina el an´lisis, el objeto A tiene un atributo con el nombre del s´
a ımbolo inicial y que
tiene sus atributos sintetizados. As´ es como transmitimos el resultado.
ı

7.2. Ficheros de configuraciń
o
Vamos ahora a programar el m´dulo de lectura de los ficheros de configuraciń. Haremos que
o o
el resultado del an´lisis sea un diccionario en el que las claves sean las variables y los valores
a
asociados sean los le´ıdos del fichero.
El analizador l´xico se escribir´ as´
e ıa ı:

1 variable None [a-zA-Z][a-zA-Z0-9]*
2 igual None =
3 valor None [0-9]+|"[^"n]*"
4 nl None (#[^n]*)?n
5 None None [ t]+

Los unicos auxiliares que necesitamos son las funciones de tratamiento de errores:
´

6 %
7 def error(linea, mensaje):
8 sys.stderr.write("Error en lńea %d: %sn" % (linea, mensaje))
ı
9 sys.exit(1)
10
11 def error_lexico(linea, cadena):
12 if len(cadena)> 1:
13 error(linea, "no he podido analizar la cadena %s." % repr(cadena))
14 else:
15 error(linea, "no he podido analizar el carćter %s." % repr(cadena))
a

Nuestro esquema de traducciń ser´:
o a

Fichero → {dic:= {}}(( L´
ınea {dic[ L´ ınea .dcha}|λ) nl)∗ { Fichero .dic:= dic}
ınea .izda]:= L´
L´
ınea → variable { L´
ınea .izda:= variable.lexema } igual valor { L´
ınea .dcha:= valor.lexema}

Pasado a metacomp:

16 %
17 <Fichero>-> @dic= {}@
18 ( (<Linea> @dic[Linea.izda]= Linea.dcha@)? nl )*
19 @Fichero.dic= dic@ ;
20
21 <Fichero>-> error



22 @error(mc_al.linea(), "lńea mal formada")@
ı
23 ;
24
25 <Linea>-> variable
26 @Linea.izda= variable.lexema@
27 igual valor
28 @Linea.dcha= valor.lexema@
29 ;
30

Como ves, hemos utilizado el operador de opcionalidad para representar la disyunciń ( Linea |λ).
o

8. Resumen del tema
El analizador semńtico tiene dos objetivos:
a

• Hacer comprobaciones que no se hagan durante el an´lisis l´xico o sintćtico.
a e a
• Crear una representaciń adecuada para fases posteriores.
o

Implementaremos el an´lisis semńtico en dos partes:
a a

• Mediante esquemas de traducciń dirigidos por la sintaxis.
o
• Recorriendo el AST.

Un esquema de traducciń dirigido por la sintaxis aãde a las gram´ticas:
o n a

• Acciones intercaladas en las partes derechas de las reglas.
• Atributos asociados a los no terminales.

Dos tipos de atributos: heredados y sintetizados.
Las acciones deben garantizar que se evalán correctamente los atributos.
u
Se pueden implementar los esquemas de traducciń sobre los analizadores sintćticos inter-
o a
pretando los atributos como par´metros y aãdiendo el c´digo de las acciones al c´digo del
a n o o
analizador.
El c´lculo de algunos atributos y algunas comprobaciones semńticas son m´s fćiles sobre
a a a a
el AST.
La tabla de s´
ımbolos se puede implementar eficientemente mediante una tabla hash.
Las comprobaciones de tipos se complican si se introducen nombres. Dos criterios:

• Equivalencia de nombre.
• Equivalencia estructural.

La interpretaciń se puede realizar mediante recorridos del AST.
o
metacomp permite implementar c´modamente esquemas de traducciń dirigidos por la sin-
o o
taxis.

Semantico.apun

Más contenido relacionado

La actualidad más candente (20)

Destacado (6)

Similar a Semantico.apun (20)

Semantico.apun