Podcast sobre Sintaxis y Semántica de Lenguajes

Kapitoly

El código a investigar

Análisis Léxico: Los bloques de construcción

Análisis Sintáctico: Las reglas del juego

Análisis Semántico: ¿Esto tiene sentido?

Errores Léxicos y Sintácticos

El Caos de los Errores Semánticos

Mitos del Compilador

Gramáticas y Precedencia

Asociatividad y Resumen Final

Přepis

Alba: ¿Alguna vez te has preguntado cómo tu móvil sabe que una app tiene un error, incluso antes de que la ejecutes? O cómo Netflix sabe exactamente qué serie recomendarte después de que terminas una.

Mateo: Detrás de toda esa magia, hay alguien, o algo, leyendo código línea por línea, casi como un profesor súper estricto corrigiendo un examen. Y la forma en que lo hace es exactamente lo que vamos a desglosar hoy.

Alba: Suena complicado, pero fascinante. Estás escuchando Studyfi Podcast, donde hacemos que lo complejo se vuelva sencillo.

Mateo: ¡Exacto! Y hoy nos ponemos en modo detective de código.

Alba: Vale, Mateo, entonces tenemos un caso. Un fragmento de código en lenguaje C. ¿Qué es lo primero que hacemos cuando nos enfrentamos a él?

Mateo: Lo primero es mirarlo, como si fuera una escena del crimen. Tenemos una función con algunas líneas que, a simple vista, pueden parecer normales. Pero nuestro trabajo es analizarla en tres niveles: léxico, sintáctico y semántico.

Alba: Léxico, sintáctico y semántico. Suenan a clases de lengua, no de programación.

Mateo: ¡Es que es muy parecido! Piénsalo así: el análisis léxico es como pasar el corrector ortográfico. El sintáctico es revisar la gramática. Y el semántico es comprobar si la frase, aunque esté bien escrita, tiene sentido.

Alba: Entendido. Ortografía, gramática y significado. ¡Vamos a ello!

Alba: Empecemos por el nivel léxico. El prompt menciona algo llamado "tokens". ¿Qué es un token?

Mateo: ¡Buena pregunta! Un token es la unidad mínima con significado para el compilador. Es como una palabra o un signo de puntuación en un texto. Por ejemplo, la palabra int es un token, el número 3 es otro, el signo = es otro, y hasta el punto y coma ; es un token.

Alba: Vale, entonces el análisis léxico es simplemente... ¿dividir el código en estas pequeñas piezas?

Mateo: Exactamente. Es el primer paso. El analizador léxico recorre el código y se asegura de que todas las "palabras" y símbolos que usas existan en el diccionario del lenguaje. En nuestro fragmento de código, todas las piezas, como int, float, los paréntesis, los números... son válidas.

Alba: ¿Así que a nivel léxico, nuestro código pasa la prueba?

Mateo: Sí, es léxicamente correcto. Pasa el "corrector ortográfico". No hay símbolos raros ni palabras inventadas. En total, si los contamos, este pequeño fragmento se descompone en 50 tokens.

Alba: Cincuenta tokens. Parece mucho para tan pocas líneas.

Mateo: ¡Cada cosita cuenta!

Alba: Muy bien, la ortografía está bien. Pasemos a la gramática: el análisis sintáctico. Según los apuntes, aquí es donde encontramos el primer problema.

Mateo: Aquí es donde la cosa se pone interesante. La sintaxis son las reglas de cómo ordenar los tokens para formar sentencias válidas. Es como en español, no puedes decir "galletas yo como", tienes que decir "yo como galletas".

Alba: ¿Y dónde se rompe la regla en nuestro código?

Mateo: El problema está en la línea return {a+1};. La gramática de C dice que después de return puedes poner una expresión, como a+1, y luego un punto y coma. Pero no puedes envolver esa expresión entre llaves {}. Eso es sintácticamente incorrecto.

Alba: Ah, ya veo. Es como poner un signo de puntuación donde no va.

Mateo: ¡Exacto! Ahora, aquí viene la parte curiosa. Algunos compiladores modernos, como GCC, son un poco más permisivos y podrían aceptar esta sintaxis como una extensión no estándar del lenguaje. Pero si nos ceñimos a las reglas oficiales de C, es un error garrafal.

Alba: O sea, es como si tu profesor de lengua te permitiera usar una palabra de la jerga local en un ensayo formal. No es lo correcto, aunque se entienda.

Mateo: ¡Me encanta esa analogía! Es perfecta. Así que, sintácticamente, nuestro código está suspenso.

Alba: Vale, suspenso en sintaxis. Pero la cosa no acaba aquí. Viene el análisis semántico, el del significado. Y parece que aquí hay... varios problemas.

Mateo: Sí, aquí es donde el código se desmorona por completo. La semántica se pregunta: aunque la frase esté bien construida, ¿tiene lógica? Puedes decir "El coche púrpura duerme furiosamente", que es sintácticamente perfecta, pero no tiene ningún sentido.

Alba: Entendido. ¿Cuáles son los sin-sentidos de nuestro código?

Mateo: Bueno, para empezar, declaramos una variable int b dentro de la función, cuando ya habíamos recibido una variable b como parámetro. Es como si en una conversación te presentas a alguien que ya conoces. El programa se confunde. ¡Error semántico número uno!

Alba: Vale, no se puede declarar la misma variable dos veces en el mismo ámbito. ¿Qué más?

Mateo: Luego, intentamos usar una variable llamada c_ en la línea a = c_;. Pero la variable que declaramos antes se llamaba _c. Ese guion bajo al principio lo cambia todo. Estamos intentando usar una variable que no existe.

Alba: ¡Un error de identidad! Como llamar a alguien por el nombre de su hermano gemelo.

Mateo: ¡Exacto! Y el remate final está en la declaración del array: _c={-1,2.0,5,4};. Le decimos al programa: "Oye, créame un cajón con 3 espacios". Y a continuación intentamos meterle cuatro cosas. ¡No caben! Es un error lógico, semántico.

Alba: Vaya, así que nuestro código es un desastre léxico-ortográfico perfecto, pero un caos gramatical y de significado. ¿Y qué pasa con la pregunta sobre si un símbolo puede ser operador y puntuación a la vez?

Mateo: Gran punto. La respuesta es no, no en la misma sentencia simple. Un símbolo tiene un rol definido. El signo = es un operador de asignación. El punto y coma ; es un terminador de sentencia, un signo de puntuación. No hacen doblete. Cada uno tiene su trabajo y no se mezclan.

Alba: Entendido. Así que, para resumir: el análisis de código es un proceso de tres pasos que va de lo más superficial a lo más profundo. Primero, que las palabras existan (léxico); segundo, que las frases estén bien ordenadas (sintáctico); y tercero, que todo el conjunto tenga sentido (semántico).

Mateo: Lo has clavado. Y entender estos tres niveles es fundamental no solo para aprobar un examen, sino para escribir código que realmente funcione y no cause dolores de cabeza. Ahora, hablando de estructuras y reglas, hay otro concepto clave que debemos abordar...

Alba: Ok, entonces el análisis sintáctico construye el árbol. Pero, ¿qué pasa cuando el código está... mal? Tengo aquí un ejemplo que me gustaría que viéramos.

Mateo: ¡Perfecto! Los ejemplos con errores son los mejores para aprender. Dispara.

Alba: Vale, es un código corto. Imagina una línea que dice año contador += 1;.

Mateo: ¡Opa! Ahí ya tenemos el primer problema. Es un error léxico. La letra ñ no pertenece al alfabeto inglés estándar que usan la mayoría de los lenguajes de programación.

Alba: ¡Claro! El compilador ni siquiera reconoce esa letra como un token válido. Es como si le habláramos en un idioma que no entiende.

Mateo: Exactamente. Ahora, supongamos que corregimos eso. ¿Qué más ves? Hay otra línea que dice return b y luego, en la línea siguiente, una llave de cierre }.

Alba: Mmm... ¿Le falta el punto y coma al final del return?

Mateo: ¡Diste en el clavo! Ese es un error sintáctico de manual. La 'gramática' del lenguaje dice que esa instrucción debe terminar con un punto y coma. Sin él, la estructura de la oración está rota.

Alba: Entendido. Léxico es el alfabeto, sintáctico es la gramática. Pero luego viene lo semántico, ¿no? El significado.

Mateo: Ahí es donde se pone interesante. Imagina que el código intenta sumar dos textos, como si fueran números. El compilador se queda... perplejo. Es un conflicto de tipos.

Alba: Sería como pedirle que sume "hola" más "mundo". ¿Qué resultado daría? ¿"holamundo"?

Mateo: Ojalá fuera tan listo. A veces simplemente da un error o, peor, convierte el texto a números raros y te da un resultado sin sentido. También hay otro error grave en el ejemplo: intenta acceder a la posición 5 de un arreglo que solo tiene 5 elementos.

Alba: Pero... si tiene 5 elementos, ¿no va de la posición 1 a la 5?

Mateo: ¡Ah, trampa clásica! En programación, casi siempre empezamos a contar desde cero. Así que las posiciones válidas son 0, 1, 2, 3 y 4. Intentar usar la posición 5 es salirse de los límites.

Alba: ¡Wow! Eso suena peligroso.

Mateo: Lo es. Es decirle al programa que escriba en una zona de memoria que no le pertenece. Una receta para el desastre.

Alba: Ok, esto aclara mucho. Para cerrar, tengo unas afirmaciones rápidas, tipo verdadero o falso. ¿Listo?

Mateo: ¡Adelante!

Alba: Primera: Si una expresión es sintácticamente correcta, es derivable de la gramática formal o BNF.

Mateo: Verdadero. Esa es la definición. Si la sintaxis es correcta, es porque sigue las reglas de la gramática.

Alba: Segunda: ¿Podemos eliminar la etapa de preprocesamiento en la compilación?

Mateo: Falso. Nunca se puede eliminar. Aunque no haya nada que hacer, el compilador siempre pasará por esa etapa, es parte del proceso.

Alba: Y la última: ¿la expresión d = 1 = h es sintácticamente correcta?

Mateo: ¡Para nada! Eso es un error sintáctico. No puedes asignarle un valor a una constante como el número 1. Es como intentar cambiar el significado del color azul. ¡Simplemente no se puede!

Alba: Me queda clarísimo. Esto de las gramáticas y las reglas es fascinante. Me deja pensando... ¿qué son exactamente las gramáticas regulares de las que hablamos? Creo que debemos profundizar en eso.

Alba: Y hablando de reglas y estructuras, eso nos lleva a nuestro último tema: la teoría de la computación. Suena… bastante intimidante, Mateo.

Mateo: Un poco, pero es más sencillo de lo que parece. Piensa en una regla de gramática súper simple: S produce 'aS' o produce 'b'. Con solo eso, puedes generar infinitas palabras como 'b', 'ab', 'aab', y así para siempre.

Alba: Entiendo, es como una pequeña fábrica de patrones. ¿Y cómo se relaciona esto con las operaciones que hacemos en programación?

Mateo: ¡Gran pregunta! Define la prioridad de los operadores. Por ejemplo, el operador 'Y' lógico (&&) siempre se resuelve antes que el 'O' (||). Esto no es arbitrario. Pasa porque su regla en la gramática está más cerca del axioma inicial.

Alba: O sea que la estructura de la gramática lo es todo. ¿Y qué pasa con la asociatividad, como en una resta seguida de una suma?

Mateo: Es el mismo principio. En la expresión '5 - 2 + 3', siempre haces la resta primero. ¿Por qué? Porque el operador de resta tiene asociatividad de izquierda a derecha. Esto se ve en la gramática porque la producción es recursiva por la izquierda.

Alba: Increíble. Entonces, las reglas que parecen abstractas en realidad dictan cómo funcionan las calculadoras y los lenguajes de programación. ¡Qué locura!

Mateo: Esa es la magia de la teoría. Y con eso, cubrimos todos los temas de hoy. Un buen repaso.

Alba: Definitivamente. Ha sido genial, como siempre. Muchísimas gracias, Mateo, por aclarar todo esto.

Mateo: Un placer, Alba. Y gracias a todos por escucharnos.

Alba: Nos oímos en el próximo episodio de Studyfi Podcast. ¡Adiós a todos!