8

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

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)

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?

John Rivers
  • 1,307
  • 10
  • 20
  • 3
    What you're describing is basically a list, unless you're admitting components of different types. In that case, however, the proposed tuple construction will also introduce infinitely many distinct types. – waldrumpus Jan 31 '13 at 09:03

1 Answers1

8

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?

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.

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.

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.

J D
  • 48,105
  • 13
  • 171
  • 274