Skip to content

Análisis Semántico. Identificación

Objetivo del Análisis Semántico

El tipo de los hijos de cada nodo ya supone una restricción sobre qué nodos se pueden conectar con qué otros en el árbol (por ejemplo, no se puede poner un objeto varDefinition como hijo de un nodo print por no ser el primero una expresión). Sin embargo, quedan aún situaciones en las que, aunque los tipos de los hijos sean válidos, no deben ser aceptadas en un programa. Un ejemplo de esto sería la asignación de un real a una variable de tipo entero. Ambos nodos son expresiones (tal y como se requiere a los hijos del nodo asignación) pero, sin embargo, el subárbol que forman esos tres nodos no debe aceptarse como válido en el AST (ya que en este lenguaje sólo se permiten asignaciones del mismo tipo).

Por tanto, una manera [demasiado] informal de explicar la misión del semántico es la de validar todos los subárboles del AST (que el padre y sus descendientes cumplan unas determinadas reglas). Si todos los subárboles son válidos, el AST será válido.

Etapas del Análisis Semántico

El análisis semántico debe hacer muchos tipos de validaciones. Aunque se podría hacer todo el análisis semántico en una sola etapa (de hecho, en muchos textos se presenta así), es más fácil de diseñar e implementar si se hace por partes. La mayor parte (no todas) de las reglas que debe comprobar el semántico son las reglas de ámbito y las reglas de tipo. Por tanto, el análisis semántico se hará en dos etapas que se corresponderán con la validación de cada uno de estos tipos de reglas:

  • Las reglas de ámbito se comprueban en la etapa de identificación.
  • Las reglas de tipo se comprueban en la etapa de comprobación de tipos.

Este capítulo tratará sobre la primera de estas dos etapas. La segunda se tratará en el siguiente capítulo.

TIP

Tal y como se ha comentado, hay más validaciones además de las relacionadas con los ámbitos y con los tipos (por ejemplo, las relacionadas con el control de flujo). Estas validaciones restantes, aunque podrían implementarse en una tercera etapa, se suelen incluir en el comprobador de tipos cuando son pocas validaciones y no merece la pena hacer un nuevo visitor para ellas.

Objetivo de la etapa de Identificación

La etapa de identificación es la primera de las dos etapas en las que se va a dividir el análisis semántico y es a la que se va a dedicar este capítulo. Esta etapa tiene que realizar dos tareas: validar y enlazar.

Validar

La primera tarea de esta fase es:

  • Comprobar que no haya definiciones repetidas.
  • Comprobar que todo símbolo que se usa en el programa ha sido definido y sea accesible desde el lugar en el que se utiliza.

Por ejemplo, ante una entrada como:

DATA
	float price;
	int price;	// Error: redefined variable

CODE
	print price;
	print value;	// Error: undefined variable

Debería notificar los siguientes errores:

bash
Error in Identification: [3:6] Variable already defined: price
Error in Identification: [7:8] Undefined variable: value

2 errors detected.

Enlazar

Aunque, estrictamente hablando, la tarea anterior es la misión fundamental de esta etapa, también debe realizar como segunda tarea el enlazado de las variables con su definición (es decir que que los nodos variable apunten a su varDefinition). La razón de esta última tarea es que las fases posteriores del compilador van a necesitar de nuevo información sobre la definición de una variable (su tipo, su dirección, etc.). Si quedan ya enlazadas en esta etapa, no habrá que repetir en fases posteriores la búsqueda de definiciones que ya se hace aquí.