Hola amiguitos, quería sugerir una funcionalidad sencillita pero muy útil a nivel de compilador.
Resulta que muchas veces hacemos INCLUDE para añadir un fichero de código a nuestro programa en el que especificamos uno o más procesos (U otras cosas).
Ya sabemos que todos los procesos tienen un número de etiquetas de "apertura" como BEGIN o LOOP igual al de etiquetas de "cierre" END.
El caso es que si nos dejamos un END en uno de los ficheros de código que incluimos, el compilador no es capaz de detectar el error hasta que la cuenta de etiquetas de "apertura" y "cierre" no salen, esto es muchas veces en el BEGIN del programa principal... Y es ahí donde salta el error y tenemos que mirarnos los ficheros modificados hasta localizar ese maldito END
Yo sugiero que el compilador, al llegar a un fichero que se carga con INCLUDE, sea capaz de contar los ENDs dentro de ese fichero para poder predecir que el error se encuentra en él...
¿Qué os parece la idea? ¿Os excita?
PD: A mí no me sucede porque estoy curado de tener esos fallos, pero a algunos de mis alumnos a veces les pasa y es una tortura ayudarles a encontrar el error :P
Yo, como truco, uso el bgdindent que hice en todos los archivos, si algún archivo no se indenta bien es que algo falla, asi que me voy a donde ha empezado a fallar y busco el error hasta que al indentar todo encuadra.
¿Con indentar te refieres a "tabular" las líneas de código hacia la derecha cuando abres etiqueta (BEGIN, LOOP, etc) y hacia la izquierda cuando cierras con END? ¿O te refieres al hecho de contar etiquetas de apertura y cierre (END) para comprobar si falta/sobra algún END?
Sorry pero es que uso siempre un lenguaje muy muy basto para referirme a ciertas tareas de programación y lo de "indentar" me suena poco familar, yo nací en un pueblo y en mi juventud he comido cosas que harían vomitar a una cabra...
Perdona, es un anglicismo, la palabra reconocida en la rae es Sangrado
http://es.wikipedia.org/wiki/Indentación
Yo hice un programilla para hacer esto, pero el propio fbmx también lo hace.
Yo, esta técnica la uso mucho a la hora de programar en c con eclipse, se que no es lo correcto pero gracias a ella gano velocidad porque programo sin preocuparme de si todo está bien alineado e incluso a veces en una misma sola línea, luego pulso control shift f y mágicamente todo el código se ordena y queda perfecto para ser entendido.
El bgdindent.exe que hice yo no es tan bueno, es decir, no separa instrucciones que estén en la misma línea, pero ayuda bastante.
nop, eso no deberia hacerse, ya que un include puede ser una porcion de codigo... incluso puede ser el inicio de un codigo incluyendo un BEGIN y en otro include o en el llamador puede estar el end...
Eso no parece muy práctico y complica su lectura, ¿No?
no, para nada...
el include es "inserta este texto aca"... eso es un include...
¿Entonces para el caso que yo hablo de "incluir" ficheros .prg en los que a priori estoy seguro que guardo declaraciones de procesos completos hay algo mejor que INCLUDE? Algo como import por ejemplo, que no pueda dar los problemas de los que hablo.
Comprendo la utilidad actual de INCLUDE y si es así no está "bien" mi sugerencia, pero creo que debería haber alguna forma de incluir teniendo en cuenta que el fichero incluido debe ser correcto en cuanto a apertura/cierre de etiquetas.
Yo he hecho eso que dice Splinter en mi motor tileado: hay una parte que la tengo que repetir en varios sitios porque hace una tarea concreta, y esta debe hacerse bajo unas determinadas condiciones, y dado que no existen subrutinas y crear funciones no me sirve porque trabajo escaso de CPU, prefiero ocupar unos cuantos bytes más en el DCB... y uso el include como si fuese la llamada a la funcion, y deja el código mucho más entendible.
Una ayuda para la apertura y cierre de etiquetas, además del sangrado, es poner el END justo despues de escribir la sentencia de apertura (por ejemplo, justo después de escribir el IF y sus condiciones) y luego escribir el código dentro.
Otra es poner después del END las barras // y dejar el comentario de lo que cierra:
while (i<35)
(codigo)
END //contador i, while o lo que mejor te lo recuerde
Sí Drumpi, es lo que hago siempre, son ya muchos años programando y muchas horas seguidas buscando esa maldita etiqueta de cierre en el proyecto que hay que presentar al día siguiente >:(
La sugerencia no es por mí, es por mis pequeños alumnos, recuerdo mis primeros encuentros con la programación y no hay cosa que produzca más dolor moral al principio que el compilador dando un error a 300 líneas de donde se encuentra realmente... Y tú preguntándote por qué no es capaz de cerrar ese END que falta xD
Nosotros entendemos cómo funcionan estas cosas, pero recordad que también una vez fuimos jóvenes y virginales.
En conclusión, se me ocurre como sugerencia un WARNING que advierta que "pueden" faltar etiquetas de cierre en el fichero xxx.prg implicado...
Pero es que no sabes en cual de todos los archivos que forman el código está el error, es imposible saberlo. Sólo si en todos ellos cierras todo lo que abres podría ser, pero con que haya un sólo if que lo cierres en otro fichero distinto, ya no se puede localizar el error.
Se puede localizar el error si para cada fichero por separado haces un conteo de etiquetas de apertura y cierre y determinas si falta/sobra alguna, de ahí se podría lanzar el WARNING indicando "xxx.prg might have a lost END tag" o algo así.
Podría, pero si se da que:
-xxx01.prg tiene un END de menos
-xxx02.prg tiene un END de más
¿Uno compensa al otro? ¿O es que has tenido DOS errores al programar? Podría dar el warning, pero no recuerdo ningún compilador que lo haga.
A mi me gusta la idea de wingate. Una advertencia para decir que tal archivo no tiene todos los ends necesarios es muy buena ayuda, ya que en el caso que sea a posta lo sabrás (sabrás que te falta un end a posta porque está en otro archivo) y en el caso de que no lo sea podrías analizar simplemente este archivo para buscar el fallo.
En el caso que tu propones pues habría dos warnings uno en el archivo en el que le falta el end, y otro en el archivo en el que le sobra un end.
Mi idea va orientada a poder "compilar" un fuente que por ejemplo sólo tenga una declaración de proceso... Y poder detectar si tiene errores.
En C por ejemplo si compilas un proyecto con varios fuentes es capaz de detectar un error de ese tipo e indicar cuál es el fuente donde falta la llave de cierre.
Cierto que INCLUDE no es lo que yo pensaba, y es "legal" que falten etiquetas de cierre... Pero me sigue pareciendo una utilidad interesante lo que propongo.
También apoyo lo de DCelso, pensad que hablo de un warning, es algo muy light.
esto implicaria un doble contexto de parseo...
Cierto, implicaría llevar "otro hilo de compilación" por separado, es una cosa peculiar...
Si lo propongo es porque ya no concibo la programación de un proyecto en Bennu por mínimo que sea sin hacer uso de varios .prg, me atrevo a poner 10 como mínimo que son los que meto para configurar vídeo / animar / controlar sonidos / cargar fnt y fpg / gravedad, etc, etc, etc, a los que se suman al menos uno por proceso "importante" en el juego, véase disparo / enemigo / interfaz / protagonista...
Entonces creo que podría ser útil... Una opción sería añadir una opción a bgdc, por ejemplo -m para que tenga en cuenta esa "compilación" para los múltiples ficheros .prg por separado.
Entiendo que es mucho pedir para un simple Warning, si supiese meter mano al código encargado de compilar... Este año tengo una asignatura de compiladores que es de las pocas que me quedan, no me importaría echar un vistazo al compilador de Bennu para ver si puedo sacar algo en limpio, ¿Qué fichero/s son? Tengo los fuentes de Bennu localizados pero me da pánico meter mano.
El código del compilador son los que están en la carpeta CORE->BGDC->SRC, busca el main.c y ve tirando del hilo para sacar el ovillo (mira los includes).
Yo recuerdo que uno de los primeros ejercicios que hacíamos el primer año de programación con pseudocódigo era precisamente el balanceo de apertura/cierre de sentencias. Claro, en pseudocódigo es fácil y bonito, hasta que no me he hecho yo mi propio "compilador" no he comprobado con horror y estupefación lo diabólicamente enrevesado del asunto. En C tienen la ventaja de que para eso se usan llaves (un único carácter, que encima no se usa para otra cosa) aunque por ejemplo los IFs de una sóla instrucción no necesitan llaves :S
A ver, sin saber prácticamente nada de compiladores:
En una variable inicializada a 0 para cada módulo le sumas 1 por cada LOOP, BEGIN, IF, LOOP, WHILE, FROM y le restas 1 por cada END
Si al final la variable no vale 0 lanzas el Warning.
Que el programa lo podría hacer yo, pero la idea es tenerlo en Bennu para editar mis .sh y mis .bat y que usen esa opción para compilar siempre.
Gracias por indicarme la ruta del compilador, voy a echar un ojo a ver qué descubro pero miedo me da :P
El problema de los compiladores son la ámplia gama de combinaciones posibles entre las letras. Puede parecer fácil buscar, por ejemplo, loop, pero ten en cuenta que hay quien lo escribe con mayúsculas, hay quien con minúsculas, con la primera en mayúsculas, alternando...
Vale, hay una función que la pone todas en mayúsculas, pero tienes que mirar que no forme parte de otra palabra, como por ejemplo dIFerente, y ya tienes que buscar espacios antes y después.
Pero miserias de la vida, después puede haber un espacio, una tabulación, un paréntesis o un error de sintaxis cualquiera, y antes, además de eso, puede estar el salto de línea de la línea anterior.
Es el fabuloso mundo de la flexibilidad del lenguaje XD. Don't panic, había una función en el código de Bennu que te devuelve un "token", que supongo que se refiere a una palabra del lenguaje, así que la cosa se simplifica mucho.
Sí, a lo del token sí que llegaba... Es de lo poco que recuerdo del año pasado, que matriculé la asignatura de compiladores y apenas pasé por clase un par de días... Si es que combinar estudios y trabajo no trae nada bueno :S
Lo de mayúsculas/minúsculas al menos con el cutre compilador que hice usando Flex y Bison no era problema, todavía no he mirado el compilador de Bennu, a ver si saco tiempo.
Gracias.