Bug al generar el código por caracteres ocultos (creo)

[gpfernandezflorio]

Me costó mucho encontrarlo pero después de muchas pruebas, esto es lo que descubrí:

Todo comenzó con un archivo que me pasaron en el cual saltaba un error de función indefinida a pesar de que la función claramente estaba definida. El archivo era muuuuuy grande pero lo reduje a lo siguiente. Como pueden ver, la función "cinco" sí está definida. Lo que me llamó la atención es que en el código fuente (que se puede observar en la consola, en la esquina inferior derecha de la imagen) los saltos de línea se representan con "\r".

Lo siguiente que hice fue abrir una nueva instancia y volver a escribir el mismo código desde cero. Al ejecutar este último, el código generado tenía "\n" en lugar de "\r":

Sin embargo, seguí explorando y descubrí otra cosa. Al borrar el comentario entre el programa y la función, el código sí funciona.

Esto me lleva a concluir que el problema no es por los caracteres "\r" sino que es una combinación estre eso y las barras de comentario.

[fidel-ml]

Este bug tendría que verlo Pablo B...

[foones]

El análisis que hace Perla es correcto. Creo que no se trata de un bug estrictamente hablando. Más detalles:

• En la sintaxis léxica de Gobstones las líneas están delimitadas por saltos de línea (LF, \n).

• Los comentarios single-line comenzados por // se extienden hasta el final de la línea, es decir, hasta que se encuentra un LF (\n), o hasta el final del archivo en su defecto.

• Los retornos de carro (CR, \r) se consideran caracteres blancos, que se ignoran de igual manera que los espacios y los tabs pero no delimitan líneas.

• Es decir que, en el siguiente programa:

  //
  function cinco() {
  return (5)
  }

  si las aparentes líneas se delimitan por CR (\r), para el analizador léxico hay una sola línea, y el programa de arriba es equivalente a este otro:

  // function cinco() { return (5) }

• No sé cuál es la proveniencia el código problemático, pero diría que el problema está en el generador (editor de textos que se usó para editarlo u otro programa que haya generado ese archivo). Como dato de color, en sistemas Windows las aparentes líneas se delimitan con la combinación CR+LF (\r\n) y en sistemas tipo *nix, incluyendo Linux y OS X, se delimitan con LF (\n). Delimitar las aparentes líneas sólo con CR (\r) era el antiguo estándar de Mac; no tengo experiencia como usuario ni desarrollador en Mac, pero creo que esta convención se abandonó hacia los ~2000 en favor de LF (\n).

[gpfernandezflorio]

• El código original lo escribió en la misma interfaz de Gobtones Sr pero copió y pegó una definición desde un pdf.
• Si el parser ignora los \r entonces el editor también debería hacerlo así que sí es un bug, pero no del parser sino del editor que te muestra de forma incorrecta los saltos de línea y, por lo tanto el sintax highlight.
• También hay algo raro en el editor ya que parece que al presionar la tecla enter inserta un \r o un \n según lo que ya hay en el texto. Como que intenta mantener la convención. Así que si copiás y pegás una parte de código con un \r, todo el archivo pasa a usar \r como saltos de línea. Creo que eso también se podría arreglar, ya sea reemplazando los \r por \n o directamente eliminándolos.

[fidel-ml]

Esto es en al versión vieja, que ya no mantenemos, y es un error los suficientemente oscuro e infrecuente como para no gastar pólvora en chimangos... En la nueva versión usaremos un editor diferente, y ahí sí habría que ver de chequear este tema...