Hola a todos, y feliz Navidad.
Estoy estos días dándole vueltas a un par de cosas de Forth que
no me gustan. A ver qué pensáis vosotros. Creo que, a estas alturas,
con máquinas que corren entre 2 y 4 GHz, el tema del rendimiento
puede pasar a segundo plano. Entonces, son otras las características
del lenguaje que hay que valorar. La más importante, para mí, es la
simplicidad. Pero no hay que simplificar más allá de cierto punto,
porque entonces vienen los problemas. Uno de ellos es la representación
de los números. En una máquina de cálculo, la representación de
los números es esencial y, rendimiento aparte, creo que sólo dos
lenguajes dieron en el clavo a la primera: uno es Cobol, con su
PIC, y otro es Lisp, con su aritmética de precisión arbitraria
y su soporte nativo para enteros, reales, racionales y complejos,
y el hecho de que pueda trabajar de forma transparente con tipos
diferentes. Por contra, la nula sobrecarga de los operadores en
Forth, hace la programación más delicada. Pero lo que me molesta
especialmente no es eso, sino que, por lo que parece, los cálculos
con enteros y los cálculos con reales REQUIEREN DE ALGORITMOS
DIFERENTES. La razón de eso es que no existen f>r ni fr>. Así que
uno escribe una palabra para enteros y usa >r y r>, pero quiere
hacer una versión para reales y no sólo cambia el tipo, sino que
el mismo algoritmo ya no puede usarse. O bien se implementan
unos f>r, fr> propios, o bien se usan variables locales, o bien
se introduce una cantidad indeseable de ruido de pila. Yo siempre
trato de evitar las variables locales, excepto cuando no usarlas
es peor.
He ensayado algunas opciones, pero no me satisfacen. Una de ellas
es representar los reales como racionales, pero rápidamente se
salen de rango, pues con demasiada frecuencia una fracción no
puede reducirse, al ser numerador y denominador primos entre sí.
Otra es usar un entero para la parte entera y otro entero para
la parte fraccionaria, pero de nuevo el rango queda limitado. En
máquinas de 32 bits, esta representación puede ser suficiente
para la suma y la resta, pero no para multiplicación y división.
Ahora bien, imaginemos un Forth con todo lo que hace que Forth
sea Forth (create, does>, immediate, postpone, pila, control del
compilador, diccionario y alguna cosilla más), PERO con un sólo
tipo numérico. Un número es un número, que se representa mediante
una cadena de tamaño suficiente como para no tener que preocuparse
por el rango. Parte entera y parte fraccionaria, y aritmética
de punto fijo, mucho más simple y suficiente para casi cualquier
cosa. Por ejemplo, 20 dígitos para la parte entera y 18 para la parte
fraccionaria son suficientes para cualquier aplicación, incluidas
aplicaciones científicas (adoptando unidades convenientes, claro).
Entonces, la pila no contendría números, sino punteros a las cadenas
que los representan. Este hipotético Forth contendría únicamente
una familia de operadores aritméticos. Nos olvidamos de familias {x}
y {fx} y de los operadores mixtos, y de operadores para números
sin signo.
Desgraciadamente, vendrían otros problemas: la interacción entre
números hardware (direcciones) y números software. Por ejemplo,
cuando quiero la dirección base de un vector (número hardware)
para sumarle un desplazamiento (proveniente de una operación con
números software). Pero esto no me parece tan grave.
En fin, a ver qué pensáis del tema.
Saludos.
Javier Gil.
El 22 de diciembre de 2015, 19:21, javier gil<[email protected]> escribió:
> Gracias Marcos, ¡espero la lista de comentarios! Algo que tengo
> en mente desde hace tiempo y que solucionaría algunos de los
> defectos que comentas, es fundir en un sólo texto "Introducción
> a Forth" y "Ejercicios de programación en Forth". Sobre el código,
> seguro que una segunda pasada me permite hacerlo mejor. Pasa que
> las cosas se dejan un tiempo en reposo y al cabo del tiempo
> muchos fallos saltan a la vista…
>
> Saludos.
> Javier.
>
> El 22 de diciembre de 2015, 13:09, Marcos Cruz [email protected]
> [forth-es]<[email protected]> escribió:
>
>>
>>
>> En/Je/On 2015-12-21 20:42, javier gil [forth-es] escribió / skribis /
>> wrote :
>>
>> > Agradezco los elogios de Mauricio, sobre todo porque el libro quedó
>> > algo por debajo de lo que yo hubiese querido, y porque en una escala
>> > de 0 a 10 me pongo un 5 en Forth, no más.
>>
>> Javier, como ya te dije en otra ocasión, tu libro es muy bueno. Cuando
>> lo encontré casualmente hace unos pocos años me sorprendió mucho por ese
>> motivo. En mi opinión, los contenidos están bien organizados y bien
>> explicados. Siempre lo recomiendo como primer contacto con Forth, aparte
>> de los clásicos de Brodie.
>>
>> Un defecto que le encuentro, sin embargo, es la legibilidad de algunos
>> de los ejemplos de código, que o bien no tienen comentarios de pila (lo
>> que siempre es una barrera gratuita, pero mucho más para un
>> principiante) o bien, para ser comprensibles, necesitarían ser
>> factorizados en palabras pequeñas que hagan operaciones claras.
>>
>> Como te comenté, te mandaré algunas sugerencias sobre pequeños detalles.
>>
>> Aparte de eso, quizá el enfoque general del libro sea demasiado teórico,
>> es decir, explica bien cómo se harían muchas operaciones y cálculos en
>> Forth, pero quizá el principiante se quede al final con la sensación de
>> que no sabe cómo empezar a escribir un programa en Forth para solucionar
>> un problema práctico. De hecho, algo que me resultó muy sorprendente es
>> esta frase de la página 5: «el objeto de Forth, al menos desde el punto
>> de vista del libro que tiene en sus manos, no es escribir código Forth,
>> sino _pensar en Forth_».
>>
>> Esto es solo una impresión, pues cuando conocí el libro yo ya tenía
>> mucha experiencia con Forth y por tanto no lo he usado para aprender el
>> lenguaje. Me gustaría oír la opinión de alguien que sí lo haya usado
>> como primer contacto con Forth.
>>
>> > Por cierto, que el libro fue revisado por alguien que sabe mucho más,
>> > y que, ahora que lo pienso, debería de estar en la lista: Jorge
>> > Acereda Maciá.
>>
>> No lo conozco. ¿Tienes contacto con él? Si es así, escríbele o mándame
>> aparte su dirección para que lo invite.
>>
>> --
>> Marcos Cruz
>> http://programandala.net
>>
>>
>
>
[Se han eliminado los trozos de este mensaje que no contenían texto]
