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

问题描述

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

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元组vs对的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！