> 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. ; Pero como decía alguien, hay que hacer ; las cosas simples, pero no más de lo ; necesario. Para mí, la multiplicidad de ; operadores (enteros, reales, mixtos, ; simples y dobles) es una consecuencia ; indeseable de haber ido más allá de lo ; necesario en la búsqueda de la simplicidad. ; Por otro lado, lo que era necesario y quizás ; imprescindible en 1969 ya no es cuestión: ; con memoria infinita y almacenamiento ; infinito, la realidad es muy distinta. ; Y una mínima sobrecarga de operadores, ; añade una pequeña cantidad de código al ; sistema Forth y una cantidad más pequeña ; aún de complejidad conceptual. 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? ; En efecto. Se trata de poder escribir ; 2 1.98 * sin preocuparse. El operador * ; ha de manejar las 4 posibilidades: ; real-real, real-entero, entero-real, ; entero-entero. Es poco trabajo, y poca ; complicación > 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? ; La idea era que los paréntesis fuesen ; sólo una ayuda visual, que a nivel ; léxico serían tratados exactamente igual ; que espacios en blanco. Después de pensarlo ; mejor, no me parece necesario. Abandono la idea. > 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? ; Creo que hay por ahí un Forth que usa ; sólo reales. No habría inconveniente. ; Para mí la cuestión es otra: conceptualmente ; un entero es una cosa distinta que un real. ; Y me gusta que en código eso quede reflejado. > 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. ; Como digo arriba, las condiciones de 1970 ; no son las actuales. Los bloques ; son atractivos porque son simples. Pero, ; a estas altura, un archivo de texto ; es algo mucho más natural. Además, yo no ; voy a escribir un Forth en vacío, sino sobre ; un sistema operativo. Eso me da la posibilidad ; de llamar a mi editor desde el entorno, abrir ; el archivo, modificarlo, y volver al entorno. > 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. ; Uso "palabra" y "operador" como sinónimo. ; Precisamente, porque quiero que TODO sean ; palabras del diccionario, y puesto que escribo ; un intérperte, éste encontraría la palabra '+' ; y podría actuar inmediatamente. Pero quiero ; que todo esté en el diccionario, así que el ; intérprete buscará la definición '+', y en el ; código correspondiente encontrará el bytecode de ; la operación suma. Ese bytecode indexará un ; array de punteros a función, así que se llamará ; a la función del intérprete encargada de la suma. ; Fíjate en Gforth: si escribes : >r >r ; obtendrás ; un error. Pero si escribes : + + ; no habrá error. ; Es claro que '+' y '>r' reciben un tratamiento diferente. ; Yo quiero completa uniformidad. > 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. ; Estoy terminando un pequeño proyecto que usa ; nappgui. Cuando esté terminado lo compartiré. ; Veréis cómo se pueden escribir aplicaciones nativas ; tanto para OSX como para Windows en C puro y duro. ; Nada de librerías, sólo la tecnología nativa de ; cada sistema operativo. > 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. ; ¡Qué le vamos a hacer! 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? ; Aunque no entiendo exactamente qué quieres ; decir, la respuesta más rápida que se me ; ocurre es ésta: un Forth a mi medida ; son algo así como 40K, y eso es mucho ; menos que luchar con librerías externas. ; Además, si uso Forth uso Forth, no me gusta ; mezclarlo con otras cosas. Para uso general ; ya tengo C y para cálculo científico ya ; tengo Matlab. Y si esas librerías se ; escriben en Forth, ¿qué ventaja hay? ; Forth es por el placer de Forth. ; Conclusión: mi conclusión es que no tengo ; todavía una conclusión. La idea de usar ; enteros y reales en la misma pila me parece ; buena, pero un Forth puro que use sólo enteros ; me parece algo así como un objeto que se ; contempla con placer, independientemente de ; su mayor o menor utilidad. Y además, todavía ; no he explorado completamente las posibilidades ; de los enteros para representar reales. Quizás ; encuentre una solución que me satisfaga ; completamente. ; Otra cosa que quería comentaros: ni se me había ; ocurrido pensar en implementar variables locales. ; No las he usado nunca. ¡Nunca! ¿Vosotros las ; usáis? Un Forth cualquiera ¿debería tenerlas ; de todas formas? Saludos. Javier Gil El 11 de octubre de 2016, 18:23, Marcos Cruz forth...@programandala.net [forth-es]<forth-es@yahoogroups.com> escribió: > > > En/Je/On 2016-10-07 09:16, javier gil javgi...@gmail.com [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 > > [Se han eliminado los trozos de este mensaje que no contenían texto]
