UTNianos

Versión completa: [SSL] Sintácticamente correcto
Actualmente estas viendo una versión simplificada de nuestro contenido. Ver la versión completa con el formato correcto.
Tengo una duda del Volúmen 1 de SSL =P

(Pag. 49) escribió:Ejemplo 21
De acuerdo a las definiciones escritas en BNF, una sentencia como while 2+3 do a:=5 sería una sentencia sintácticamente correcta ya que 2+3 es una <expresión> válida. Sin embargo, sabemos que la condición de un while en Pascal debe ser una expresión BOOLEANA.

No me queda claro esto

while 2+3 do a:=5
Es una sentencia sintácticamente correcta en dónde?
Es una sentencia sintácticamente incorrecta en Pascal no? Confused

En el ejercicio que está arriba en la misma página * Ejercicio 25 *
not 436
y
A or 12
Son expresiones sintácticamente incorrectas en Pascal
pero son expresiones sintácticamente correctas en otro lado? Confused

O sea, porqué se puede derivar algo que va a ser sintácticamente incorrecto? huh
Si estas con C, por ejemplo:


int a;
while (2+3)
a = 5;



es sintacticamente y semanticamente valido, y compila sin warnings...en C al menos la condicion del while tiene que ser una expresion casteable a int, que se considera falsa si es 0 y verdadera si es distinta de 0. Pascal me parece que distingue entre enteros y variables booleanas, entonces "while 2+3" no tendria sentido sintacticamente (por lo menos no en Pascal).

Para las otras dos, es la misma idea.."436" no es una expresion booleana en Pascal, y tampoco lo son "A" ni "12". Por eso no son sintacticamente correctas...todo eso suponiendo que los operadores "not" y "or" son exclusivamente para variables/expresiones booleanas.

La biblioteca de C99 (no es ANSI C) provee un archivo, stdbool.h, que define una forma de expresar variables y valores booleanos en C, pero siguen siendo enteros. Es algo parecido a esto:



typedef int bool
#define true 1
#define false 0




Spoiler: Mostrar
Obviamente, C > Pascal, pero creo que ya lo sabiamos todos (?) =D
Hay una parte que dice
(Pag. 49) escribió:En algunos casos, no solo se debe conocer la definición en BNF del constructo, sino también las RESTRICCIONES que aparecen escritas en lenguaje natural.

Por lo tanto, aunque se pueda derivar, si no cumple las RESTRICCIONES, no es sintácticamente correcto supongo.

Pero esas RESTRICCIONES en lenguaje natural parece que aparecen en Pascal, porque para C con que se pueda derivar ya es sintácticamente correcto (por lo menos eso haciamos en clase Confused)

Spoiler: Mostrar
Pascal es alto FAIL {?} =P
Claro, supongo que si se tiene una expresión sintácticamente correcta en un lenguaje (de programación o no), entonces se puede derivar a BNF siempre y cuando tenga definición. O sea, los operadores lógicos en el lenguaje natural vendrían a ser equivalentes a los de Pascal, pero no a los de C. Por ejemplo,

"Hola" \[\wedge\] "Chau"
no está definido ni en Pascal ni en la lógica tradicional, pero en C se puede hacer tranquilamente:


char a[] = "Hola";
char b[] = "Chau";
if (a && b)
puts("Verdadero");
else puts("Falso");




Tambien se puede hacer con punteros, con cualquier cosa =P


int a;
char b;
if (&a || &b)
puts("wtf xd");




En realidad, en el primer ejemplo, a y b son punteros...nunca va a dar falso porque una cadena constante nunca puede ser NULL (0).
Bueno parece que en C también hay RESTRICCIONES para las BNF
(Pag. 53) escribió:En el MROC
"Restricciones", sección en la que figuran ciertas restricciones existentes sobre el constructo definido en "Sintaxis" y que la BNF no expresa totalmente (como ya hemos visto en el caso de Pascal);

O sea, si en un parcial/final me preguntan si algo es sintácticamente correcto, tengo que saberme todas las Restricciones que en el libro no las encuentro Confused
La verdad si te digo te miento...todo esto te lo estaba intentando contestar con un poco de google-fu y lo que sé de C nada mas =P

No tengo idea como preguntarán en los parciales...
Lo ví y me sirvió Fuck_yea

Igual me quede con la duda que dije antes

(25-04-2011 21:56)batty escribió: [ -> ]Bueno parece que en C también hay RESTRICCIONES para las BNF
(Pag. 53) escribió:En el MROC
"Restricciones", sección en la que figuran ciertas restricciones existentes sobre el constructo definido en "Sintaxis" y que la BNF no expresa totalmente (como ya hemos visto en el caso de Pascal);

O sea, si en un parcial/final me preguntan si algo es sintácticamente correcto, tengo que saberme todas las Restricciones que en el libro no las encuentro Confused
Si me estas preguntando eso, entonces no entendiste lo que decia el link
Como dije, para que sea sintácticamente correcto sé que tengo que poder derivarlo y debe cumplir con las restricciones.

Pero mi pregunta era si esas restricciones las tengo que conocer todas? porque supuestamente en el libro te tiran un par nomás y capaz en el parcial/final toman alguna restricción que está en el MROC (Manual de Referencia Oficial de C) Confused

Por ejemplo en el libro hay un ejercicio que pregunta si _ (un guión bajo) y __ (dos guines bajos) son identificadores válidos en ANSI C. (La respuesta no está en el libro)
Y siguiendo la BNF, lo puedo derivar, pero no se si existe una restricción sobre los guiones bajos, seguramente esté en el MROC.
Toman cosas así ?

Carucha
Bueno, en los ejercicios preguntan a secas si es "sintácticamente correcto", pero parece que uno tiene que especificar si para el compilador o programador Confused

gonnza escribió:Entonces, si bien lo podes obtener derivandolo, y cumple con las restricciones (suponete que esta permitido hacer con numeros esto, en el examen va a estar reemplazado por a b y c, pero te lo puse con numeros para que sea mas claro) es sintacticamente correcto para el compilador, pero sintacticamente incorrecto para el programador
(es decir, el compilador te lo pasa como correcto, pero vos como programador no era lo que querias obtener)
Fuck_yea Gracias gonnza! Fuck_yea

Y a todos los que me respondieron también
Spoiler: Mostrar
Fuck_yea
Me alegra haberte podido responder sin escribir nada, reutilice respuestas, eso se llama saber usar el paradigma foristico

Fuck_yea
URLs de referencia