f# - Tuplas N-ary vs pares

ocaml tuples

Question

En Ocaml, las tuplas con aries diferentes tienen diferentes tipos y constructores de valor:

# let a = (1, 2, 3);;
val a : int * int * int = (1, 2, 3)
# let b = (1, (2, 3));;
val b : int * (int * int) = (1, (2, 3))

Tenga en cuenta que el segundo ejemplo (b) es más flexible que el primero (a) porque "cola" de b - (2, 3) - en sí es un valor válido:

# let (_, c) = b;;
val c : int * int = (2, 3)
# let d = snd b;;
val d : int * int = (2, 3)

¿Cuál es la razón para no analizar "(1, 2, 3)" como "(1, (2, 3))" y en su lugar introducir cantidad infinita (o, peor aún, finita) de nuevos tipos y constructores de valores para diferentes arios ?

Answer 1

¿Cuál es la razón para no analizar "(1, 2, 3)" como "(1, (2, 3))" y en su lugar introducir cantidad infinita (o, peor aún, finita) de nuevos tipos y constructores de valores para diferentes arios ?

El sistema de tipo ML fue diseñado en la búsqueda de una comprobación más fuerte del tipo estático con el fin de detectar tantos errores en el momento de la compilación como sea posible.

Su sugerencia debilitaría considerablemente el sistema de tipos porque ya no podría distinguir entre (1, 2, 3) y (1, (2, 3)) que es un movimiento en la dirección opuesta.

En la práctica, puedo decirle que ML haciendo tales distinciones ha detectado errores reales en mi código de producción en el pasado. Valoro el diseño ML en este contexto.