En/Je/On 2016-10-07 09:16, javier gil [email protected] [forth-es] escribió / skribis / wrote :
> Lo que más me molesta de Forth y de otros lenguajes, es el rango > limitado y la precisión con que se representan los números. Al mismo > tiempo, me gusta la simplicidad de Forth, pero creo que fue un poco > lejos, buscando una implementación sencilla antes que un uso sencillo. > Así que todos esos operadores aritméticos mixtos y tener una pila > separada para reales nunca me gustó. La simplicidad de implementación es lo que hace que se pueda hacer funcionar un Forth en prácticamente cualquier máquina, real o virtual, y que un solo programador pueda comprender el sistema en su totalidad. Para mí es una de las características del lenguaje que lo hacen tan atractivo. Desgraciadamente, en los complejos sistemas operativos modernos es muy difícil preservarla. La cuestión de la precisión de los números y la separación de los reales tiene justificaciones prácticas e históricas, pero para ciertas aplicaciones en plataformas actuales no tiene ventaja. Para mí no es problema, porque nunca he necesitado usar reales, y me gusta usar Forth en sistemas clásicos. > Habrá una sola pila y esa pila podrá albergar reales de 64 bits o > enteros también de 64 bits. Habrá un bit de tipo y los operadores > básicos estarán sobrecargados mínimamente para manejar los tipos. ¿Quieres decir que los operadores serán únicos para todas las combinaciones de tipos y contendrán código para detectar el tipo de los números involucrados y actuar en consecuencia? > Por ejemplo, el uso a discreción de paréntesis para hacer más claro el > código. Sabemos que al codificar una palabra pensamos en pequeñas frases > que hacen dos o tres operaciones cada vez. Si estas frases se indican entre > paréntesis, el código queda mejor. Las frases de código que haga una función específica, que se pueda abstraer de su contexto, suelen escribirse como palabras, por claridad, incluso aunque solo se usen una vez en el resto del programa. También pueden separarse visualmente del código circundante, del resto de la palabra de la que forman parte, con dobles espacios o saltos de línea. Por eso no entiendo qué utilidad quieres dar a los paréntesis, como separadores de frases de código. ¿Quieres decir que no harían nada y serían solo una ayuda visual? ¿O servirían para delimitar los bloques de las estructuras, en lugar de las palabras estándar? ¿Puedes dar un ejemplo de cómo los usarías? > El poder tener simultáneamente valores reales y enteros en expresiones > será una mejora también. ¿Has pensado en un Forth que solo usara reales? Al fin y al cabo, los enteros son un subconjunto. Si se trata de aplicaciones científicas, ¿hay ventajas en distinguir ambos tipos con un bitio y hacer que los operadores (si no te entendido mal) sean comunes e inteligentes? ¿No sería más sencillo ahorrar la distinción y usar solo números reales? ¿O es la imprecisión de los formatos de reales lo que hace los enteros imprescindibles? > Me olvido de los bloques. Sólo trabajo con archivos de texto. Los bloques simplifican enormemente la implementación en máquinas con recursos limitados, por ejemplo las plataformas de 8 bitios. Pero para el desarrollo en plataformas modernas los bloques no tienen ventajas, salvo tal vez como como capa sobre la que escribir un sistema de memoria virtual, que es lo que en el fondo son los bloques, o de base de datos. En cualquier caso, implementar bloques en Forth es muy sencillo; hay sistemas Forth que no los incluyen en su núcleo, sino como un pequeño archivo de texto opcional. > A un nivel más bajo: implementación tradicional enhebrada. Compilación a > bytecode. Ejecución eficiente: los bytecodes indexan un array de punteros a > función. > Algunas cosas aún no las he decidido. ¿Encapsulo en palabras los operadores > básicos para que puedan tratarse como cualquier otra palabra? Por ejemplo, > puedo encontrar un '+' y hacer enseguida la operación. O puedo al arrancar > cargar definiciones del estilo > > : + + ; > > El primer '+' es una palabra del diccionario, sin más. El segundo '+' es > una operación elemental codificada con su bytecode correspondiente. La > ventaja de este enfoque es que puedo pedir la dirección del código de '+' > como si fuese cualquier otra definición. Habrá uniformidad. A cambio, las > operaciones más frecuentes resultarán también algo más lentas. Y aunque el > objetivo no es la velocidad, tampoco quiero un sistema lento. No entiendo esta diferencia que haces entre palabras y operadores, que no existe en Forth. ¿Es que estás pensando en una compilación en código de octetos en que cada octeto no represente una palabra del diccionario, sino una operación básica que no esté necesariamente asociada a una palabra? ¿Entonces escribirías un compilador como el de un lenguaje compilado convencional, en lugar de un _sistema Forth_ propiamente dicho? No me queda claro cuál es tu intención. > Por otro lado, estoy trabajando en otro proyecto y uso la creación de > un colega: NAppgui. Es una capa realmente delgada que encapsula las > operaciones gráficas usando tecnología nativa de cada sistema > operativo. En efecto: un sólo código C puro para crear y gestionar > elementos gráficos de aspecto y comportamiento nativo en OSX, Windows, > IOS y Android. Aplicaciones gráficas donde la parte gráfica ocupa > kilobytes, no megabytes. Estaría bien para un futuro indeterminado, > cuando mi Forth esté acabado, extenderlo para que puedan crearse > aplicaciones nativas en el sistema que se quiera. Con un núcleo que > calculo estará sobre los 30K y una parte gráfica que no creo que > supere los 100K. Eso me parece una buenísima idea. Uno de los puntos flacos de los sistemas Forth actuales es el uso de librerías gráficas que sí son accesibles desde otros lenguajes. Alguna vez he intentado probar cómo se escribiría una aplicación con interfaz gráfica con Gforth, y tuve que desistir porque me pareció demasiado complejo y poco documentado. Seguramente con los sistemas Forth comerciales sea más fácil, pero no conozco una solución multiplataforma. > creo que hemos abusado la mayoría de nosotros centrándonos > en las implementaciones Forth, y no en crear aplicaciones Forth. Eso es una autocrítica habitual entre los programadores de Forth. Como sabes, ocurre que, a partir de cierto punto, programar en Forth no puede separarse de conocer cómo funciona Forth internamente, al contrario de lo que ocurre en otros lenguajes, que prácticamente son cajas negras y cerradas que te son dadas tal cual (aunque el código sea libre, su comprensión no está al alcance del programador usuario del lenguaje en cuestión). En una implementación clásica de Forth, por ejemplo con un pequeño núcleo en ensamblador, a partir de cierto nivel de familiaridad con Forth es imposible no saber cómo funciona la implementación, y la tentación de modificarla para ajustarla a las necesidades propias es grande. De ahí hay solo un pequeño paso para escribir tu propio sistema Forth, algo que a ningún programador de C o de Lisp o de Python o de cualquier otro lenguaje conocido se le ocurriría jamás... Pero escribir programas en Forth es más importante. Durante el desarrollo de Solo Forth, mi sistema Forth para ZX Spectrum, estoy escribiendo un par de programas en él. Es la mejor manera de probarlo. De hecho empecé a escribir Solo Forth porque ninguno de los muchos sistemas Forth que hay para esta plataforma eran suficientemente potentes para escribir los programas que quería escribir, y comprobé que no me bastaba con modificar, ampliar y mejorar alguno de ellos, sobre todo teniendo en cuenta las limitaciones de la plataforma. > A mí me interesa el software científico y ahí Forth me parecía > limitado. Creo que con sobrecarga de operadores básicos, 64 bits y una > sola pila se puede escribir buen código sin sufrir. Ya sé que hay > proyectos de librerías científicas en Forth y creo que todos hemos > visto el código de Julian Noble y nos ha parecido admirable. Pero, al > mismo tiempo, a mí me parece en exceso esotérico. Me gustaría código > más natural. Bueno, es una cuestión de gustos. Pero, a largo plazo y > usando mi implementación, mi idea es hacer aplicaciones científicas. Al final estás cayendo, como casi todos, je je, en escribir tu propio sistema Forth ideal para poder escribir con él las aplicaciones que quieres. Lo que no entiendo es por qué no utilizas las capacidades de Forth para adaptar esas librerías a tus necesidades. Por ejemplo, en cualquier sistema Forth actual podrías escribir una lista de palabras que sirviera de interfaz a las librerías externas (y a tus propias palabras), de modo que cuando interpretes tu aplicación científica con esa lista de palabras en la cima del orden de búsqueda, podrás usar tu propia versión del lenguaje, sin ninguna limitación: pila única, operadores inteligentes, lo que quieras. ¿Has considerado esta opción? ¿Por qué crees que necesitas escribir una implementación propia con una variante especializada de Forth en lugar de crear una capa a tu medida sobre un sistema Forth moderno, como Gforth u otro? -- Marcos Cruz http://programandala.net
