Claus Reinke wrote:
>
> The problem with tuples is that each length of tuple comes as a separate
> piece of *syntax* in Haskell, not built in a compositional way from tuples
> of smaller length. Type classes enable meta-programming based on types,
> but not based on syntax..
>
> If you are happy with the isomorphism
>
> (T1 x T2 x ...) <-> (T1 x (T2 x (...)))
>
> you could get a slightly better handle on the problem. Currently, this
> would make the syntax a bit awkward because of the nesting, so here
> is a question to Haskell users and implementers: should/could Haskell offer
> associative type- and data-constructors? In particular, do we really need
> tuple-construction to be non-associative? That is, do we need the
> distinction between the two types in the isomorphism?
>
> If (a,b,c) would simply stand for (a , (b , c)), it should be possible to
> define some more operations on n-tuples using type classes. We lose
> some structure, but (a) what good is this structure if we have to
> repeat our function definitions for each length of tuple, and (b) the
> structure is easily recovered:
>
> data T a = T a -- T for tuple
>
> T (a,b,c) would still differ from T (a, T (b,c)), but (a,b,c) would be
> the same as (a,(b,c)).
> [(,) would just be a right-associative infix constructor]
>
> There might be some technical issues in implementing this, but note
> that the rows in TREX extensible records use associative and
> commutative construction and matching (using extra constraints to
> guarantee uniqueness of commutative matching), so it is not impossible.
I was thinking of proposing that too, but thought there were too many
difficulties. It seems lopsided that ((a,b),(c,d)) would be the same as
((a,b),c,d). I would alter the proposal slightly, adding a new built-in
constructor; let's say (:,). This fits the current Haskell rule that
constructor operators start with a colon. The new constructor would be
right-associative and would pair up any item on the left with any tuple
on the right. () would be considered the 0-tuple. I would turn the old
syntax into just sugar for applications of this new constructor.
Then: (a,b,c) === (a:,(b:,(c:,())))
just like [a,b,c] === (a: (b: (c: [])))
already.
I would allow the (,:) constructor to be used in constructing new
tuples, and in pattern-matches, while still of course allowing the sugar
syntax everywhere it is used today.
Notice that the 1-tuple could only be written as (a :, ()), since (a)
would of course not be considered a tuple.
Anybody else see the beauty of this?
Thanks,
Matt
