N元组与对 [英] N-ary tuples vs pairs

问题描述

在 Ocaml 中，不同元组的元组具有不同的类型和值构造函数:

In Ocaml, tuples with different arities have different type and value constructors:

# 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))

请注意，第二个示例 (b) 比第一个示例 (a) 更灵活，因为 b - (2, 3) 的尾部" - 本身就是有效值:

Note that second example (b) is more flexible than first (a) because "tail" of b - (2, 3) - itself is valid value:

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

不将 "(1, 2, 3)" 解析为 "(1, (2, 3))" 而是引入无限(或者更糟糕的是，有限)数量的新类型和值构造函数的原因是什么适合不同的艺人?

What is the reason to not parse "(1, 2, 3)" as "(1, (2, 3))" and instead introduce infinite (or, even worse, finite) amount of new type and value constructors for different arities?

推荐答案

不将 "(1, 2, 3)" 解析为 "(1, (2, 3))" 而是引入无限(或者更糟糕的是，有限)数量的新类型和值构造函数的原因是什么适合不同的艺人?

What is the reason to not parse "(1, 2, 3)" as "(1, (2, 3))" and instead introduce infinite (or, even worse, finite) amount of new type and value constructors for different arities?

ML 类型系统旨在追求更强大的静态类型检查，以便在编译时捕获尽可能多的错误.

The ML type system was designed in the pursuit for stronger static type checking in order to catch as many errors at compile time as possible.

您的建议会大大削弱类型系统，因为它不再能够区分 (1, 2, 3) 和 (1, (2, 3)) 这是一个相反方向的移动.

Your suggestion would weaken the type system considerably because it would no longer be able to distinguish between (1, 2, 3) and (1, (2, 3)) which is a move in the opposite direction.

在实践中，我可以告诉您，过去 ML 做出这样的区分已经在我的生产代码中发现了真正的错误.在这种情况下，我重视 ML 设计.

In practice, I can tell you that ML making such distinctions has caught real errors in my production code in the past. I value the ML design in this context.

这篇关于N元组与对的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！