[ghc-steering-committee] #475: New tuple and list syntax, rec: accept

[Richard Eisenberg]

I'm fine with dropping TupleN. It's something that I thought people would want, but I don't have to supply it -- any library could define TupleN. (To be clear, there's no new expressiveness in TupleN that we don't have without it. It's just for convenience.)

> On Feb 14, 2022, at 5:48 AM, Tom Harding <i.am.tom.harding at gmail.com> wrote:
> 
> I have a slightly different issue with `Constraints` and `CTupleN`, mostly because I don’t really understand the need for a constraint tuple larger than 2: is it not the case that a constraint tuple `(a, (b, c))` implies `(a, b, c)` and vice versa? I understand that I can distinguish between them using a pattern match, but as I understand it, they evidence exactly the same thing? I’m not sure this is exactly relevant to the proposal, but it would help me understand the motivation.

You are right that (a, (b, c)) implies (a, b, c) and vice versa. But there are at least two differences between them:

- Representation. When you write a function `(Show a, (Eq a, Num a)) => a -> a`, GHC produces a function that takes three arguments at runtime: a Show a dictionary, a pair of dictionaries for (Eq a, Num a), and an argument of type a. (As stated in the proposal, the top-level (...) => syntax is special.) So (Show a, Eq a, Num a) => ... is more efficient at runtime than (Show a, (Eq a, Num a)) => ...

- Type equality. As you suggest, we can differentiate between the two sets of constraint by pattern matching. For example, `Dict (Show a, (Eq a, Num a))` is not equal to `Dict (Show a, Eq a, Num a)`. 

I hope this helps!
Richard