Manejo de Errores Semánticos en Lenguaje Platzi

Curso de Creación de Lenguajes de Programación: Intérpretes

Contenido del curso

Introducción al desarrollo de intérpretes y lenguajes de programación

Construcción del lexer o tokenizador

Construcción del parser o analizador sintáctico

Evaluación o análisis semántico

Mejora del intérprete

Siguientes pasos

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0021:04

Manejo de Errores Semánticos en Lenguaje Platzi

Curso de Creación de Lenguajes de Programación: Intérpretes

Clase 48 de 58

Clase 48 / 58

Recursos

Cuando la sintaxis de un programa es correcta pero su significado no tiene sentido, aparecen los errores semánticos. Saber identificarlos y detener la ejecución a tiempo es fundamental para construir un lenguaje de programación robusto. Aquí se explica cómo implementar este mecanismo paso a paso, desde los tests hasta la propagación del error en el evaluador.

¿Qué es un error semántico y por qué difiere de un error de sintaxis?

Un error semántico ocurre cuando una expresión tiene la estructura correcta —paréntesis bien cerrados, puntos y comas en su lugar— pero carece de significado dentro del lenguaje [0:18]. Por ejemplo, expresiones como verdadero + falso o 5 + verdadero no representan operaciones válidas.

Este tipo de errores se conoce como type mismatch (discrepancia de tipos) cuando los operandos no son compatibles, o como unknown operator (operador desconocido) cuando la operación no está definida para ciertos tipos [0:42]. Es importante recordar que tú decides las reglas: si quisieras que -verdadero evaluara a falso, podrías hacerlo. Cada decisión define la semántica de tu lenguaje.

¿Cómo se diseñan los tests para errores semánticos?

La estrategia sigue el enfoque test-driven: primero se escriben los tests y después la implementación [1:38]. Se generan múltiples programas inválidos y se verifica que cada uno devuelva el mensaje de error correcto:

5 + verdadero → type mismatch: entero más booleano.
-verdadero → operador prefijo desconocido para booleanos.
verdadero + falso → operador infijo desconocido.
verdadero - falso → operador desconocido.
Expresiones con * o / entre booleanos → operador desconocido.

Una característica clave es que el error detiene la ejecución [2:22]. Si una línea produce un error, las líneas siguientes no deben evaluarse. Esto se valida incluyendo expresiones válidas después del error y comprobando que nunca se alcancen.

¿Cómo se implementa la clase error?

El objeto Error es sencillo: hereda de la clase base Object e implementa los métodos type e inspect [4:28]. Su constructor recibe un mensaje como string.

python class Error(Object): def init(self, message: str): self.message = message

def type(self) -> ObjectType:
    return ObjectType.ERROR

def inspect(self) -> str:
    return f"Error: {self.message}"

Además, se añade ERROR como nuevo valor en el enum ObjectType [5:02].

¿Cómo funciona la función new error y las constantes de mensajes?

Se definen tres constantes que actúan como plantillas de mensaje [5:38]:

TYPE_MISMATCH: discrepancia de tipos con formato tipo operador tipo.
UNKNOWN_PREFIX_OPERATOR: operador prefijo desconocido con formato operador tipo.
UNKNOWN_INFIX_OPERATOR: operador infijo desconocido con formato tipo operador tipo.

La función new_error recibe el mensaje plantilla y una lista variable de argumentos [6:30]. Utiliza unpacking (*args) para formatear el string dinámicamente:

python def new_error(message: str, *args) -> Error: return Error(message.format(*args))

Este patrón es equivalente al operador spread (...) en JavaScript: extrae todos los valores de la lista y los pasa como argumentos individuales al método format.

¿Dónde se propagan los errores dentro del evaluador?

La propagación es el paso más delicado. Cada punto donde antes se retornaba None ahora debe devolver una instancia de Error [7:10]:

En evaluate_prefix_expression: si el operador no es válido para el tipo, se retorna unknown prefix operator.
En evaluate_minus_operator_expression: si el operando no es entero, se retorna unknown prefix operator con el operador - [9:15].
En evaluate_integer_infix_expression: si el operador no está soportado, se retorna unknown infix operator.
En evaluate_infix_expression: si los tipos de ambos lados no coinciden, se retorna type mismatch [8:18].

¿Cómo se detiene la ejecución al encontrar un error?

En dos lugares estratégicos se verifica si el resultado es un error para interrumpir la evaluación [8:44]:

evaluate_block_statement: si el tipo del resultado es RETURN o ERROR, se deja de recorrer los statements del bloque.
evaluate_program: si el resultado es un error, se retorna inmediatamente sin continuar con el resto del programa.

Este comportamiento garantiza que un error semántico corte la ejecución de forma limpia, sin evaluar código posterior que ya no tendría sentido.

Si quieres llevar esto más lejos, un buen reto es modificar el objeto Error para que incluya el número de línea donde ocurrió el problema [10:18]. Para lograrlo, necesitarías capturar la posición en cada token durante el análisis léxico y pasar esa información al error. ¿Te animas a implementarlo?

Carlos Eduardo Gomez García

Hace 6 años

Ahhhh!! reto conseguido . Logré añadir el número de línea a los errores que salen, pero debo decir que es un trabajo MUY pesado. Si tu quieres añadirlo puedes hacerlo pero te dejo la advertencia xD. . Otra cosa, te recomiendo que hagas este cambio en un branch nuevo, ya que esto implica modificar tanto el Lexer como el Parser como el Evaluador, por lo que si sigues el curso con estos cambios es posible que tengas que agregar cosas extra para adicionar la línea a los diferentes nodos. . Aquí una captura de uno de los mensajes de error: .

. Obviamente aquí simepre me va a decir que en la línea 1 porque solo hay una línea jaja, pero en los tests puse para hacer tests en otras líneas. . Como explicación general, lo que se tiene que hacer es: .

En el Lexer: Añadir a todos los tokens en qué línea se encuentra cada token, esto implica modificar la clase Token ubicada en lpp/token.py
En el Parser: Modificar las clases del AST para que cada expresión tenga el atributo line específicando en dónde se encuentra la línea, y en cada cración de nodo dentro del parser, hay que pasar la línea: self._current_token.line 3.- En el evaluador: Hay que modificar varios métodos para que acepten las líneas que contienen los nodos (en qué línea se encuentra dicho nodo) para así poder mandar el error, esto implica también modificar las clases de cada objeto.

. Sí, es un trabajo muy pesado, tienes que modiciar casi todos los archivos, y el mayor problema es que MUCHOS tests van a fallar con cada modificación. . Para el conteo de líneas dentro del Lexer, simplemente hay que añadirle una propiedad llamada line y en cada llamada al método _read_character hay que comparar si el siguiente token es un salto de línea, es ahí cuando aumentamos en uno la línea. . Realmente explicar todos los cambios es muy largo xD Pero si quieren ver cómo lo hice yo, aquí les dejo el enlace a la comparación de los archivos nuevos (con el mensaje de en qué línea está el error incluído) versus los archivos antiguos (sin los mensajes): . Adicion de la linea en los errores (comparación de GitHub) . También les dejo el enlace hacia el explorador de archivos para que puedan ver los archivos en su estado final: . Adicion de la linea en los errores (explorador de archivos de GitHub) . La verdad es que me gustaría saber cómo lo hizo el profesor pero no encontré ningún commit/branch donde él lo haya hecho jaja

Jorge Vidoni

Hace 6 años

buenas, si bien es verdad que se tiene que modificar varios archivos el cambio es bastante simple y no toma mucho tiempo (al rededor de 30 a 40 min).

por otro lado, les dejo una sugerencia para minimizar la cantidad de cambios que tengan que hacer. Si quieren obtener el número de linea donde se da el error desde los statement, sugiero no modificar el constructor y solo agregar un método que calcule el número de linea a partir de sus token.

comparto el resultado de mis cambios:

Introducción al desarrollo de intérpretes y lenguajes de programación

Construcción de Intérpretes de Software en Python 3.8

Creación de Compiladores e Intérpretes con Lenguaje Platzi

Construcción del lexer o tokenizador

Análisis Léxico: Construcción de un Léxer para Intérpretes

Definición de Tokens en Lenguaje de Programación Platzi

Desarrollo de un Lexer con Test-Driven Development

Pruebas de Operadores, Delimitadores y Fin de Archivo en Lexer Python

Lexer: Identificación de Keywords y Tokens Complejos

Reconocimiento de Funciones en Lexer de Lenguaje de Programación

Implementación de Operadores y Condicionales en Lexer de Platzi

Implementación de Operadores de Dos Caracteres en Lexer

Creación de un REPL en Python para Lenguaje de Programación

Construcción del parser o analizador sintáctico

Construcción de un Parser para el Lenguaje Platzi

Definición de Nodos Abstractos para Árbol de Sintaxis (AST) en Python

Desarrollo de un AST en Python: Creación de la Clase Programa

Parseo de Let Statements en Lenguaje Platzi

Implementación de funciones advanced y expected tokens

Manejo de Errores en Parsers con Test Driven Development

Parseo de Return Statements en Lenguaje Platzi

Técnicas de Parsing: Top-Down y Bottom-Up

Pruebas de AST para Let y Return Statements en Parsers

Pratt Parsing: Implementación y Registro de Funciones en Python

Parseo de Identificadores en Lenguajes de Programación

Parseo de Expression Statements en Platzi Parser

Parseo de Enteros en Lenguaje Platzi

Implementación de Operadores Prefijo en Parsers

Operadores InFix en Expresiones: Implementación y Pruebas

Implementación de Operadores InFix en un Parser

Expresiones Booleanas en el Lenguaje de Programación Platzi

Evaluación de Precedencia y Testeo de Booleanos en Parsers

Evaluación de Expresiones Agrupadas en un Parser

Parseo de Condicionales en Lenguaje Platzi

Implementación de Condicionales en Parser de Lenguaje

Parsing de Funciones en Lenguaje Platzi: Creación de Nodos AST

Construcción de nodos de función en un parser AST

Llamadas a Funciones en Lenguajes de Programación

Implementación de llamadas a funciones en un parser con AST

Parseo de Expresiones en LET y RETURN Statements

Implementación de REPL para Árbol de Sintaxis Abstracta

Evaluación o análisis semántico

Evaluación Semántica en Lenguajes de Programación

Estrategias de Evaluación en Lenguajes de Programación

Representación de Nodos AST y Objetos en Python

Evaluación de Expresiones en JavaScript y Python

Implementación del Patrón Singleton para Booleanos y Nulos

Evaluación de Prefijos en Lenguaje de Programación Platzi

Evaluación de Expresiones Infix en Lenguaje Platzi

Evaluación de Condicionales en Lenguaje de Programación Platzi

Evaluación y Uso del Return Statement en Programación

Manejo de Errores Semánticos en Lenguaje Platzi

Declaración y Gestión de Variables en Lenguajes de Programación

Manejo de Ambientes y Variables en Lenguajes de Programación

Declaración de Funciones en Lenguaje de Programación Platzi

Implementación de Llamadas a Funciones en PlatziLang

Mejora del intérprete

Implementación de Strings en un Intérprete de Lenguaje de Programación

Operaciones de Concatenación y Comparación de Strings en Intérprete

Implementación de Funciones Built-in en Python

Implementación de Built-ins en el Lenguaje Platzi

Siguientes pasos

Desarrollo de Lenguaje de Programación y Estructuras de Datos en Python

Construcción de un Intérprete en Python desde Cero

Manejo de Errores Semánticos en Lenguaje Platzi