Buenos días, son las 8:45 en España y vengo de pasear por la playa, saludando al día antes de ir a trabajar. Tengo pendiente contaros mi proyecto Forth. 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ó.
He explorado en los últimos meses distintas alternativas. Todas las que se me han ocurrido, y las he seguido a ver qué impacto tenían en la implementación, que quiero mantener sencilla. No voy a extenderme describiendo los pros y los contras de los distintos caminos que he seguido, sino sólo comentados la decisión final. 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. De esta forma espero un código limpio en aplicaciones científicas. No me siento obligado con ANSI, así que le daré los toques que me gusten. 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. El poder tener simultáneamente valores reales y enteros en expresiones será una mejora también. Me olvido de los bloques. Sólo trabajo con archivos de texto. 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. 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. ¿Qué más? Pues creo que hemos abusado la mayoría de nosotros centrándonos en las implementaciones Forth, y no en crear aplicaciones Forth. 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. Aprovechar la forma que tiene Forth de escalar desde el bajo nivel para unas cuantas palabras después estar haciendo cosas de alto nivel. Bueno, ya os he contado bastante. Comentarios/críticas serán bienvenidos. Saludos. Javier Gil. [Se han eliminado los trozos de este mensaje que no contenían texto]
