Permitir el uso de otros tipos numéricos

[PalumboN]

Buenas! Este año comenzamos a usar esto en mi curso de UTN y traigo la sugerencia de permitir el uso de otros tipos numéricos más allá de Number (como Int, Float y cualquier que venga con Haskell).

Yo banco el tipo Number y es el que uso en clase, pero muchas veces mis estudiantes ven código en otro lado (Mumuki) y cuando lo quieren probar en sus proyectos les falla porque no reconoce esos tipos de datos, lo que obliga a hacer el reemplazo y es medio molesto.

Me gustaría que estén disponibles todos los tipos de números además del tan querido Number. Además esto permitiría adaptarse mejor a otros cursos: esta sea tal vez la barrera más molesta para empezar a usar este proyecto. Y creo que hay más cosas mucho muy valiosas que aporta (como el reporte de errores o la documentación en español) que un poco se pierde detrás de esta decisión.

My two cents! Muchas gracias por todo!! 🚀

[JuanFdS]

@PalumboN holis, creo que los desafío con esto son:

• ¿comportarían las funciones que usan números? Ahora mismo las que exporta del PdePreludat usan el tipo Number en vez de la typeclass Num 🤔.
• ¿Cuando escribís un número literal, que esperarías que pase?

Hay un par de alternativas que se me ocurren:

• Hacerlo opt-in, y tener alguna forma de importar "el pdepreludat con Number" o "el pdepreludat con Num" y poder cambiar entre uno y otro.
• Que convivan Number y todos los demas tipos numericos a la vez. Creo que la forma mas facil de hacer esto sería hacer que Number sea Num 🤔 , que tiene algunas desventajas como que la typeclass Num aparece más temprano pero el problema principal que estabamos atacando con Number (operaciones entre Int y Double bastante molestas) deesaparecería. Luego, otra cosa que surgiría que por ahí sae media rara es que si queremos usar Number en cualquier lugar deberíamos ver que hacemos con funciones que en el Prelude reciben un tipo especifico como Int y ahora queremos que puedan recibir tambien Number. Como por ej take.

Todavía no tengo nada decidido, pero se me ocurren esas cosas a tener en cuenta (?, de eso que opinas?

[PalumboN]

@JuanFdS Ok, sí me imaginé que el problema venía por ahí... en realidad lo que me gustaría es que las definiciones que usen Int o Float no fallen, pero que siempre se termine comportando como Number.
No se puede exportar un alias onda:

type Int = Number
type Float = Numbe

Eso lo acabo de probar y me deja tener esta definición:

doble :: Int -> Int
doble numero = numero + numero

Lo que estoy viendo / pensando es que tiene algunos problemas:

• Me deja tener esta definición:

doble :: Int -> Float
doble numero = numero + numero

Lo cual es raro, pero me la banco

• Y en la consola no falla si se pasa un flotante

*Spec Library Spec> doble 2
4
*Spec Library Spec> doble 2.4
4.8

Lo cual tampoco me jode mucho. Bah, pago ese precio por el hecho que les compile el código.

---

Qué les parece? Mete más ruido?

[JuanFdS]

jajajaja ese era el hackazo que decía que se me había ocurrido por telegram 😅.

Y mmm, no me termina de cerrar exponer un Int que pueda tener decimales, me gustaría primero ver si se nos ocurren otras cosas.

Igual, algo bueno de el hack este es que lo pueden agregar facil a algun repo que ya les den armado a sus alumnes (?. Pueden agregar esos 2 type alias a algun modulo que usen o importen y avisarles que con eso el codigo que vean en apuntes o mumuki les deberia funcionar lo mas bien local 👌🏾

@fdodino @ludat ustedes que piensan?

[fdodino]

A mí me preocupa más la resistencia de les docentes que la de les alumnes. A largo plazo creo que la estrategia que me convence es:

1. poner los sinónimos de tipo como un workaround didáctico de incluir a docentes con dudas
2. sensar que tengamos una mayoría de gente usando pdepreludat
3. cambiar los apuntes y Mumuki (ya 2022)
4. terminar de cerrar la discusión didáctica: para mí diferenciar los tipos Float / Int es una decisión negativa para un curso inicial de Funcional, didácticamente solo aporta ruido y confusión empeoradas por la respuesta a la pregunta :t 2.