Tipos de suma: ¿por qué en Haskell es `show (Int | Double)` diferente a `(show Int) | (mostrar Doble) `

¿Por qué no son equivalentes?

show $ if someCondition then someInt else some double

y

if someCondition then show someInt else show someDouble

Entiendo que si aísla la if ... elseparte en el primer ejemplo de una expresión en sí misma, entonces no puede representar su tipo con un tipo de suma anónima, el tipo de Int | Doublealgo que podría hacer fácilmente en TypeScript (mencionando TypeScript porque es el tipo usé el idioma a menudo y eso admite los tipos de Suma), y tendría que recurrir al uso de los Eitherdatos que luego llamaría show.

El ejemplo que di aquí es trivial, pero para mí tiene más sentido pensar "Ok, vamos a mostrar algo, y ese algo depende de someCondition" en lugar de "Ok, si alguna condición es verdadera, entonces muestra algo, de lo contrario, muestra algo doble", y también permite para una menor duplicación de código (aquí el programa se repite dos veces, pero también podría ser una aplicación de función larga y, en lugar de una if ... else, podría haber> 2 ramas para considerar)

En mi opinión, debería ser fácil para el compilador verificar si cada uno de los tipos que forman el tipo de suma (aquí Int | Double) podría usarse como parámetro para showfuncionar y decide si los tipos son correctos o no. Aún mejor es que la showfunción siempre devuelve un stringsin importar los tipos de parámetros, por lo que el compilador no tiene que llevar consigo todas las "ramas" posibles (por lo que todos los tipos posibles).

¿Es por elección que tal característica no existe? ¿O lo está implementando más difícil de lo que creo?

Todas las partes de una expresión deben estar bien escritas. El tipo de if someCondition then someInt else someDoubletendría que ser algo así exists a. Show a => a, pero Haskell no admite ese tipo de cuantificación existencial.

Actualización: como Chi señala en un comentario , esto también sería posible si Haskell tuviera soporte para los tipos de unión / intersección (que no son lo mismo que los tipos de suma / producto), pero desafortunadamente no.

Hay tipos de productos con sintaxis ligera, escrita (,), en Haskell. Una cosa sería que un tipo de suma con una sintaxis ligera, algo así (Int | String), sería una gran idea. La realidad es mas complicada. Veamos por qué (me estoy tomando algunas libertades Num, no son importantes).

if someCondition then 42 else "helloWorld"

Si esto debería devolver un valor de tipo como (Int | String), ¿qué debería devolver el siguiente?

if someCondition then 42 else 0

(Int | Int)obviamente, pero si esto es distinto de lo normal, Intentonces estamos en serios problemas. Por (Int | Int)lo tanto, debe ser idéntico a simple Int.

Uno puede ver de inmediato que esto no es solo una sintaxis ligera para los tipos de suma, sino una característica de lenguaje completamente nueva. Un tipo diferente de sistema de tipos si se quiere. ¿Deberíamos tener uno?

Veamos esta función.

mysteryType x a b = if x then a else b

Ahora que tipo mysteryTypetiene? Obviamente

mysteryType :: Bool -> a -> b -> (a|b)

¿Correcto? ¿Qué pasa si ay bson del mismo tipo?

let x = mysteryType True 42 0

Esto debería ser claro Intcomo hemos acordado anteriormente. Ahora a mysteryTypeveces devuelve un tipo de suma anónima, y ​​otras veces no, dependiendo de los argumentos que pase. ¿Cómo combinarías un patrón con esa expresión? ¿Qué demonios puedes hacer con él? Excepto cosas triviales como "show" (o cualquier método de otras clases de tipos de las que sería una instancia), no mucho. A menos que agregue información de tipo de tiempo de ejecución al idioma, es decir, typeofestá disponible, y eso hace que Haskell sea un idioma completamente diferente.

Así que sí. ¿Por qué no es Haskell un TypeScript? Porque no necesitamos otro TypeScript. Si desea TypeScript, ya sabe dónde encontrarlo.