06 Analisis Sintactico

Compiladores
Introducción al Análisis Sintáctico
Gramáticas de Contexto Libre,

Arboles de Parseo y Derivaciones
Resumen
• Overview del análisis léxico
• Qué es análisis sintáctico
• Gramáticas libres de contexto
• Derivaciones y árboles de parseo
• Top-down vs. Bottom-up Parsing
• Grámaticas Ambiguas
• Implementando un Parser
Oscar Bonilla 2 Universidad Galileo

Anatomia de un Compilador
Programa (character stream)
Analizador Léxico (Scanner)
Token Stream
Analizador Sintáctico (Parser)
Arbol de Parseo
Generador de Código Intermedio
Representación Intermedia
Optimizador
Representación Intermedia Optimizada
Generador de Código
Código en Assembler
Resumen de Análisis Léxico
• El analizador léxico crea tokens a partir de un
character stream
• Los tokens se definen usando expresiones
regulares

Expresiones Regulares,
Gramáticas y Lenguajes
• Una expresión regular puede ser escrita usando:
– Caracteres en el alfabeto
– Operadores de expresiones regulares:
‘*’ ‘·’ ‘|’ ‘+’ ‘?’ ‘(‘ ‘)’
– Ejemplo:
(-| ε) ·(0|1|2|3|4|5|6|7|8|9)+ · (. ·(0|1|2|3|4|5|6|7|8|9)*)?
• Un lenguaje regular es un lenguaje definido por

una expresión regular

Expresiones Regulares,
Gramáticas y Lenguajes
• Qué hay acerca de las variables simbólicas?
– Ejemplo:
num = 0|1|2|3|4|5|6|7|8|9
posint = num · num*
int = (ε | -) · posint
real = int · (ε | (. · posint))
• Sólo son una abreviación, llamada “syntactic
sugar”
– Ejemplo:
(-| ε) ·(0|1|2|3|4|5|6|7|8|9)+ · (. ·(0|1|2|3|4|5|6|7|8|9)*)?

Resumen de Análisis Léxico
• El analizador léxico crea tokens a partir de un
character stream
• Los tokens se definen usando expresiones
regulares
• Las expresiones regulares pueden mapearse a
un Automaton Finito No Determinístico (NFA)
– Por construcción simple
• NFA se transforma a un DFA
– Algoritmo de transformación
– Ejecutar un DFA es fácil
Resumen
• Qúe es análisis sintáctico
• Derivación y Arboles de Parseo
• Gramáticas Ambiguas

Sintaxis y Semántica de un
Lenguaje de Programación?
• Sintaxis
– Como se ve un programa
– Representación textual o estructura
– Es posible una definición matemática precisa
• Semántica
– Cuál es el significado de un programa
– Es más difícil dar una definición matemática

Por qué hacer análisis sintáctico?
• Podemos proveer una definición precisa y fácil
de entender
• Una gramática apropiada imparte estructura a
un lenguaje de programación
• Podemos construir automáticamente un parser
que determine si el programa es sintácticamente
correcto
• Ayuda en el proceso de traducción
• Fácil modificar/añadir al lenguaje
Anatomia de un Compilador
Programa (character stream)
Analizador Léxico (Scanner)
Token Stream
Arbol de Parseo
Generador de Código Intermedio
Representación Intermedia
Optimizador de Código
Representación Intermedia Optimizada
Generador de Código
Código en Assembler
Entrada y Salida de un Parser
Entrada: - (123.3 + 23.6)
Token Stream Arbol de Parseo

minus_op
left_paren_op
-
num(123.3)
plus_op
( )
num(23.6)
right_paren_op
123.3 23.6
+

Definición de la Sintaxis
• Tenemos que proveer una definición precisa y
fácil de entender de la sintaxis del lenguaje de
programación
• Podemos usar expresiones regulares?

– Podemos usar un lenguaje regular para definir un
lenguaje de programación?

Ejemplo: Scope Jerárquico
Procedure foo(integer m, integer n, integer j) {
for i = 1 to n do {
if (i == j) {
j = j + 1;
m = i*j;
}
for k = i to n {
m = m + k;
}
}
}

Ejemplo: Scope Jerárquico
Procedure foo(integer m, integer n, integer j) {
for i = 1 to n do {
if (i == j) {
j = j + 1;
m = i*j;
}
for k = i to n {
m = m + k;
}
}
}
• Problema de los paréntesis balanceados

– Ejemplo: {{}{{{}{{}}}}}

Problema de los paréntesis
balanceados
• Podemos definir esto usando una expresión regular?

balanceados
NO!

balanceados
NO!
• Intuición
• Número de paréntesis abiertos debe ser igual a

número de paréntesis cerrados
• Necesitamos mantener un conteo o necesitamos
recursión
• Además: NFA’s y DFA’s no pueden ejecutar conteo
sin límites

balanceados
• Hay alguna gramática que defina esto?
<S>  ( <S> ) <S> | ε
• La definición es recursiva
• Esta es una gramática libre de contexto
– Es más expresiva que las expresiones regulares

Resumen
• Qué es análisis sintáctico?
• Derivación y Arboles de Parseo

Definiendo Context-Free Grammars
(CFGs)
• Terminales
– Símbolos para strings o tokens
• No terminales
– Variables sintácticas
• Símbolo de Inicio
– Un no-terminal especial es designado
• Producciones
– La forma en que los terminales y no-terminales son
combinados para formar strings
– Un no-terminal en el lado izquierdo (LHS) y un string de
terminales y no-terminales en el lado derecho (RHS)

Ejemplo de una CFG
<S>  ( <S> ) <S> | ε

Ejemplo de una CFG
<S>  ( <S> ) <S>
<S>  ε

Ejemplo de una CFG
<S>  ( <S> ) <S>
Terminales
<S>  ε

Ejemplo de una CFG
<S>  ( <S> ) <S>
No-terminales
<S>  ε

Ejemplo de una CFG
<S>  ( <S> ) <S>
Símbolo de Inicio: <S>

<S>  ε

Ejemplo de una CFG
<S>  ( <S> ) <S>
Producciones
<S>  ε

Los lenguajes regulares son un subconjunto
de los lenguajes libres de contexto
Expresión Regular Gramática libre de contexto
a <A>  a
Si p y q son expresiones regulares, usando CFGs y <Q>
p·q <S>  <Q>
p|q <S>  

<S>  <Q>
p* <S>  <S> 

<S>  ε
Los lenguajes regulares son un subconjunto
de los lenguajes libres de contexto
Expresión Regular Gramática libre de contexto
Si p es una expresión regular, usando una CFG ,
Qué es?
??? <S>  <S> 
<S>  
P? ???

Entonces por qué usar expresiones
regulares?
• Separar el análisis sintáctico en partes léxica y no-
léxica es una buena modularización
• Las reglas léxicas son simples y pueden ser expresadas

usando expresiones regulares
• Las expresiones regulares son más concisas
• Las implementaciones de analizadores léxicos para

expresiones regulares son más eficientes
Creando una CFG
• Tenemos que crear una CFG a partir de las
definiciones del lenguaje
• Hay muchas cosas involucradas

– Vamos a ver algunas de ellas en clase
• Veamos un lenguaje simple

Ejemplo: Una CFG para expresiones
• Expresiones aritméticas simples con + y *
– 8.2 + 35.6
– 8.32 + 86 * 45.3
– (6.001 + 6.004) * (6.035 * -(6.042 + 6.046))
• Terminales (o tokens)
– num para todos los números
– plus_op (‘+’), minus_op (‘-’), times_op(‘*’),
left_paren_op(‘(‘), right_paren_op(‘)’)
• Cuál es la gramática para todas las expresiones
posibles?
<expr>  <expr> <op> <expr>

<expr>  ( <expr> )
<expr>  - <expr>
<expr>  num
<op>  +
<op>  *


<expr>  - <expr>
<expr>  num Terminales
<op>  +
<op>  *


<expr>  - <expr>
<expr>  num Terminales
<op>  +
<op>  *


<expr>  - <expr>
<expr>  num No-terminales
<op>  +
<op>  *


<expr>  - <expr>
<expr>  num No-terminales
<op>  +
<op>  *


<expr>  - <expr>
<expr>  num Símbolo de Inicio:
<op>  + <expr>
<op>  *


<expr>  - <expr>
<expr>  num Producciones
<op>  +
<op>  *


<expr>  - <expr>
<expr>  num
<op>  +
<op>  *

<expr>  <expr> <op> <expr> | ( <expr> )

| - <expr> | num
<op>  + | *

Pregunta: Cuál es el lenguaje
definido por esta CFG?
<S>  a<S>a | aa

Resumen
• Overview de análisis léxico
• Derivaciones y Arboles de Parseo

Derivaciones
• Cómo mostramos que una secuencia de tokens
es aceptada por una CFG?
• Una producción es usada para derivar una
secuencia de tokens a partir del símbolo de
inicio
• Dados los strings , y 
y una producción A  
Un solo paso de la derivación es
A  
Ejemplo de Derivación
• Gramática
<expr>  <expr><op><expr> | (<expr>) | -<expr> | num
<op>  + | *
• Entrada
36 * ( 8 + 23.4)
• Token Stream
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>  <expr><op><expr>
<expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>  <expr> <op> <expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’

num ‘*’ ‘(‘ num ‘+’ num ‘)’

num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>  num
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>  num
 num <op> <expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<op>  *
 num <op> <expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<op> *
 num <op> <expr>
 num ‘*’ <expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>  (<expr>)
 num <op> <expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>  (<expr>)
 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’

 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’

 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>  num
 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>  num
 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<op> +
 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<op> +
 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
 num ‘*’ ‘(‘ num ‘+’ <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
 num ‘*’ ‘(‘ num ‘+’ <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’


 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
 num ‘*’ ‘(‘ num ‘+’ <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>  num
 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
 num ‘*’ ‘(‘ num ‘+’ <expr> ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>  num
 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
 num ‘*’ ‘(‘ num ‘+’ <expr> ‘)’
 num ‘*’ ‘(‘ num ‘+’ num ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’

 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
 num ‘*’ ‘(‘ num ‘+’ <expr> ‘)’
 num ‘*’ ‘(‘ num ‘+’ num ‘)’
num ‘*’ ‘(‘ num ‘+’ num ‘)’
Arbol de Parseo
• Representación gráfica de la estructura parseada
• Muestra la secuencia de derivaciones efectuada

– Nodos internos son no-terminales
– Hojas son terminales
– Cada nodo padre es el lado izquierdo (LHS) y los
hijos son el lado derecho (RHS) de una producción

Ejemplo de Arbol de Parseo
<expr>

<expr>
<expr> <op> <expr>

<expr>  num
<expr>
<expr> <op> <expr>
num

<op>  ‘*’
<expr>
<expr> <op> <expr>
num *

<expr>  ‘(‘ <expr> ‘)’
<expr>
<expr> <op> <expr>
<expr>
num * ( )

<expr>
<expr> <op> <expr>
<expr>
num * ( )
<expr> <op> <expr>

<expr>  num
<expr>
<expr> <op> <expr>
<expr>
num * ( )
<expr> <op> <expr>
num
<op>  ‘+’
<expr>
<expr> <op> <expr>
<expr>
num * ( )
<expr> <op> <expr>
num +
<expr>  num
<expr>
<expr> <op> <expr>
<expr>
num * ( )
<expr> <op> <expr>
num + num
num ‘*’ ‘(‘ num ‘+’ num ‘)’
<expr>
<expr> <op> <expr>
<expr>
num * ( )
<expr> <op> <expr>
num + num
Resumen

Derivaciones left-most vs. right-most
• Leftmost derivation
– En el string, encontramos el no-terminal de más a la
izquierda y le aplicamos una producción
– El ejemplo anterior fue de una leftmos derivation
• Rightmost derivation
– Encontramos el no-terminal de más a la derecha y le
aplicamos una producción

Ejemplo de Right-Derivation
Producción:
String: <expr>
<expr>

Producción: <expr>  <expr> <op> <expr>
String: <expr> <op> <expr>
<expr>
<expr> <op> <expr>

Producción: <expr>  ‘(‘ <expr> ‘)’
String: <expr> <op> ‘(‘ <expr> ‘)’
<expr>
<expr> <op> <expr>
<expr>
( )

String: <expr> <op> ‘(‘ <expr> <op> <expr> ‘)’
<expr>
<expr> <op> <expr>
<expr>
( )
<expr> <op> <expr>

Producción: <expr>  num
String: <expr> <op> ‘(‘ <expr> <op> num ‘)’
<expr>
<expr> <op> <expr>
<expr>
( )
<expr> <op> <expr>
num
Producción: <op>  ‘+’
String: <expr> <op> ‘(‘ <expr> ‘+’ num ‘)’
<expr>
<expr> <op> <expr>
<expr>
( )
<expr> <op> <expr>
+ num
String: <expr> <op> ‘(‘ num ‘+’ num ‘)’
<expr>
<expr> <op> <expr>
<expr>
( )
<expr> <op> <expr>
num + num
Producción: <op>  ‘*’
String: <expr> ‘*’ ‘(‘ num ‘+’ num ‘)’
<expr>
<expr> <op> <expr>
<expr>
* ( )
<expr> <op> <expr>
num + num
String: num ‘*’ ‘(‘ num ‘+’ num ‘)’
<expr>
<expr> <op> <expr>
<expr>
num * ( )
<expr> <op> <expr>
num + num
String: num ‘*’ ‘(‘ num ‘+’ num ‘)’

<expr>
<expr> <op> <expr>
<expr>
num * ( )
<expr> <op> <expr>
num + num
 <expr>
 <expr> <op> <expr>
 <expr> <op> ‘(‘ <expr> ‘)’
 <expr> <op> ‘(‘ <expr> <op> <expr> ‘)’
 <expr> <op> ‘(‘ <expr> <op> num ‘)’
 <expr> <op> ‘(‘ <expr> ‘+’ num ‘)’’
 <expr> <op> ‘(‘ num ‘+’ num ‘)’
 <expr> ‘*’ ‘(‘ num ‘+’ num ‘)’
 num ‘*’ ‘(‘ num ‘+’ num ‘)’

Top-down vs. Bottom-up Parsing
• Normalmente escaneamos de izquierda a
derecha
• Left-most derivation refleja top-down parsing

– Comenzamos con el símbolo inicial
– Terminamos con el string de tokens

Top-down Parsing
• Left-most derivation
 <expr>
 num <op> <expr>
 num ‘*’ ‘(‘ <expr> ‘)’
 num ‘*’ ‘(‘ <expr> <op> <expr> ‘)’
 num ‘*’ ‘(‘ num <op> <expr> ‘)’
 num ‘*’ ‘(‘ num ‘+’ <expr> ‘)’
 num ‘*’ ‘(‘ num ‘+’ num ‘)’
Top-down vs. Bottom-up Parsing
• Normalmente escaneamos de izquierda a
derecha
• Left-most derivation refleja top-down parsing

– Comenzamos con el símbolo inicial
– Terminamos con el string de tokens
• Right-most derivation refleja bottom-up parsing

– Comenzamos con el string de tokens
– Terminamos con el símbolo inicial
Bottom-up Parsing
• Right-most derivation
 <expr>
 <expr> <op> ‘(‘ <expr> ‘)’
 <expr> <op> ‘(‘ <expr> ‘+’ num ‘)’’
 <expr> <op> ‘(‘ num ‘+’ num ‘)’
 <expr> ‘*’ ‘(‘ num ‘+’ num ‘)’
 num ‘*’ ‘(‘ num ‘+’ num ‘)’
Bottom-up Parsing
 <expr>
 <expr> <op> ‘(‘ <expr> ‘)’
 <expr> <op> ‘(‘ <expr> ‘+’ num ‘)’’
 <expr> <op> ‘(‘ num ‘+’ num ‘)’
 <expr> ‘*’ ‘(‘ num ‘+’ num ‘)’
 num ‘*’ ‘(‘ num ‘+’ num ‘)’
Bottom-up Parsing
 num ‘*’ ‘(‘ num ‘+’ num ‘)’
 <expr> ‘*’ ‘(‘ num ‘+’ num ‘)’
 <expr> <op> ‘(‘ num ‘+’ num ‘)’
 <expr> <op> ‘(‘ <expr> ‘+’ num ‘)’
 <expr> <op> ‘(‘ <expr> ‘)’
 <expr>
Resumen

Otro Ejemplo
• Entrada:
124 + 23.5 * 86
• Token Stream:
num ‘+’ num ‘*’ num

Otro Ejemplo
Producción:
String: <expr>
<expr>

Otro Ejemplo
<expr>
<expr> <op> <expr>

Otro Ejemplo
Producción: <expr>  <num>
String: num <op> <expr>
<expr>
<expr> <op> <expr>
num

Otro Ejemplo
Producción: <op>  ‘+’
String: num ‘+’ <expr>
<expr>
<expr> <op> <expr>
num +

Otro Ejemplo
String: num ‘+’ <expr> <op> <expr>
<expr>
<expr> <op> <expr>
<expr> <op> <expr>

num +

Otro Ejemplo
String: num ‘+’ num <op> <expr>
<expr>
<expr> <op> <expr>
<expr> <op> <expr>

num +
num

Otro Ejemplo
String: num ‘+’ num ‘*’ <expr>
<expr>
<expr> <op> <expr>
<expr> <op> <expr>

num +
num *

Otro Ejemplo
String: num ‘+’ num ‘*’ num
<expr>
<expr> <op> <expr>
<expr> <op> <expr>

num +
num * num

Otro Ejemplo

<expr>
<expr> <op> <expr>
<expr> <op> <expr>

num +
num * num

Otro Ejemplo
• Hay otro orden de derivación?

Otro Ejemplo
String: <expr>
<expr>

Otro Ejemplo
<expr>
<expr> <op> <expr>

Otro Ejemplo
<expr>
<expr> <op> <expr>
num

Otro Ejemplo
<expr>
<expr> <op> <expr>
num
Pero también podemos usar esta producción

Otro Ejemplo
Producción:
<expr>
<expr> <op> <expr>
Pero también podemos usar esta producción

Otro Ejemplo
String: <expr> <op> <expr> <op> <expr>
<expr>
<expr> <op> <expr>
<expr> <op> <expr>

Otro Ejemplo
String: num <op> <expr> <op> <expr>
<expr>
<expr> <op> <expr>
<expr> <op> <expr>
num

Otro Ejemplo
Producción: <op>  <+>
String: num ‘+’ <expr> <op> <expr>
<expr>
<expr> <op> <expr>
<expr> <op> <expr>
num +

Otro Ejemplo
String: num ‘+’ num <op> <expr>
<expr>
<expr> <op> <expr>
<expr> <op> <expr>
num + num

Otro Ejemplo
String: num ‘+’ num ‘*’ <expr>
<expr>
<expr> <op> <expr>
<expr> <op> <expr>

*
num + num

Otro Ejemplo
<expr>
<expr> <op> <expr>
<expr> <op> <expr>

* num
num + num

Otro Ejemplo

<expr>
<expr> <op> <expr>
<expr> <op> <expr>

* num
num + num

Mismo string – Dos derivaciones
num ‘+’ num ‘*’ num
<expr> <expr>
<expr> <op> <expr> <expr> <op> <expr>
<expr> <op> <expr> <expr> <op> <expr>

num + * num
num * num num + num
124 + (23.5 * 86) = 2145 (124 + 23.5) * 86 = 12685

La Gramática es Ambigua
• Aplicar diferentes ordenes de derivación
produce árboles de parseo diferentes
• Esto no es bueno!
– Lleva a resultados ambiguos
– Muy probablemente va a producir resultados
inesperados
• Algunas veces el reescribir la gramática con
más no-terminales va a eliminar la ambiguedad

La Gramática Ambigua
<expr>  - <expr>
<expr>  num
<op>  +
<op>  *

Eliminando la Ambiguedad
<expr>  <expr> + <term>
<expr>  <term>
<term>  <term> * <unit>
<term>  <unit>
<unit>  num <expr>  <expr> <op> <expr>
<unit>  ( <expr> )
<expr>  - <expr>
<expr>  num
<op>  +
<op>  *
Eliminando la Ambiguedad

<expr>
<expr> <term>
+
<term> <term> <unit>
*
<unit> <unit>
num
num num
Primer ejemplo en la nueva gramática
<expr>
num ‘*’ ‘(‘ num ‘+’ num ‘)’
<term>
<term> <unit>
*
<unit> ( <expr> )
num <expr> <term>
+
<term> <unit>
<unit> num
num
Pregunta: Es esta gramática
ambigua?
<stmt>  if <expr> then <stlist>

<stmt>  if <expr> then <stlist> else <stlist>

Pregunta: Cómo la hacemos no
ambigua?
<stmt>  if <expr> then <stlist>

<stmt>  if <expr> then <stlist> else <stlist>

Resumen

Implementando un Parser
• La implementación de un parser para algunas
CFG’s puede ser muy difícil
– Tenemos que ver el input y elegir una producción
– No podemos elegir la producción correcta sin ver
que viene en el input (looking ahead)

Ejemplo de look ahead
• Gramática
<stmt>  a <long> b
<stmt>  a <long> c
<long>  x <long> | x
• Input string “axxxxxxxxxxxxxxxxx…….”
• Puede que tengamos que ver un montón

de símbolos del input antes de decidirnos
por una producción
• Implementar un parser para algunas CFG’s
puede ser muy difícil
– No podemos elegir una producción sin look ahead
• Hay varias técnicas
– Cada una puede manejar algunas CFG’s
– Categorización de las técnicas

( )

( )
L - parsear de izquierda a derecha
R – parsear de derecha a izquierda

( )
L - leftmost derivation
R - rightmost derivation

( )
Número de caracteres de lookahead

( )
– Ejemplos: LL(0), LR(1)

Siguiente Clase
• Cómo implementar un Parser
• Cómo construir un parser engine
para un parser shift-reduce
• Vamos a ver
– LR(0) Parser
Engine
– LR(1)
– LALR(1)

Resumen
• Diferencia entre análisis léxico y análisis
sintáctico
• Arboles de Parseo
• Derivaciones left-most y right-most
• Top-down and bottom-up parsing
• Implementación de Parsers
Grupos
• Ya tienen que tener grupos
• Si no tienen grupo todavía, hagánlo!
• Los listados de grupos van a estar en el Web
• Si no están en un grupo en el Web hablen con

Andreaq

06 Analisis Sintactico

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

06 Analisis Sintactico

Cargado por

Copyright:

Formatos disponibles

Compiladores

Introducción al Análisis Sintáctico

Gramáticas de Contexto Libre,

Oscar Bonilla 2 Universidad Galileo

Oscar Bonilla 4 Universidad Galileo

• Un lenguaje regular es un lenguaje definido por

Oscar Bonilla 5 Universidad Galileo

Oscar Bonilla 6 Universidad Galileo

Oscar Bonilla 8 Universidad Galileo

Oscar Bonilla 9 Universidad Galileo

Token Stream Arbol de Parseo

Analizador Sintáctico (Parser)

Oscar Bonilla 12 Universidad Galileo

• Podemos usar expresiones regulares?

Oscar Bonilla 13 Universidad Galileo

Oscar Bonilla 14 Universidad Galileo

• Problema de los paréntesis balanceados

Oscar Bonilla 15 Universidad Galileo

Oscar Bonilla 16 Universidad Galileo

Oscar Bonilla 17 Universidad Galileo

• Número de paréntesis abiertos debe ser igual a

Oscar Bonilla 18 Universidad Galileo

<S>  ( <S> ) <S> | ε

Oscar Bonilla 19 Universidad Galileo

Oscar Bonilla 20 Universidad Galileo

Oscar Bonilla 21 Universidad Galileo

Oscar Bonilla 22 Universidad Galileo

Oscar Bonilla 23 Universidad Galileo

Oscar Bonilla 24 Universidad Galileo

Oscar Bonilla 25 Universidad Galileo

Símbolo de Inicio: <S>

Oscar Bonilla 26 Universidad Galileo

Oscar Bonilla 27 Universidad Galileo

p|q <S>  <P>

p* <S>  <S> <P>

Si p es una expresión regular, usando una CFG <P>,

Oscar Bonilla 29 Universidad Galileo

• Las reglas léxicas son simples y pueden ser expresadas

• Las expresiones regulares son más concisas

• Las implementaciones de analizadores léxicos para

• Hay muchas cosas involucradas

• Veamos un lenguaje simple

Oscar Bonilla 31 Universidad Galileo

<expr>  <expr> <op> <expr>

Oscar Bonilla 33 Universidad Galileo

<expr>  <expr> <op> <expr>

Oscar Bonilla 34 Universidad Galileo

<expr>  <expr> <op> <expr>

Oscar Bonilla 35 Universidad Galileo

<expr>  <expr> <op> <expr>

Oscar Bonilla 36 Universidad Galileo

<expr>  <expr> <op> <expr>

Oscar Bonilla 37 Universidad Galileo

<expr>  <expr> <op> <expr>

Oscar Bonilla 38 Universidad Galileo

<expr>  <expr> <op> <expr>

Oscar Bonilla 39 Universidad Galileo

<expr>  <expr> <op> <expr>

Oscar Bonilla 40 Universidad Galileo

<expr>  <expr> <op> <expr> | ( <expr> )

Oscar Bonilla 41 Universidad Galileo

Oscar Bonilla 42 Universidad Galileo

Oscar Bonilla 43 Universidad Galileo