Tuple-like constructors

[Robert Dockins]

On Feb 6, 2006, at 2:40 PM, Mieszko Lis wrote:

> i would argue against treating tuples as pure syntactic sugar for  
> nested pairs; since the nesting carries hierarchical information, i  
> would expect (x,y,z) used in place of (x,(y,z)) to cause an error.

Well, these would be desugared differently....

(x,y,z) === Tuple x (Tuple y (Tuple z ()))
(x,(y,z)) === Tuple x (Tuple (Tuple y (Tuple z ())) ())

which maintains the distinction, just like in lisp (maybe I remember  
lisp syntax...) where

'(x y z)

is not the same as

'(x '(y z))


> bluespec classic implemented n-tuples this way, and the error  
> messages were rather ugly.  not to mention that explaining this to  
> beginners feels like a "oh yeah, it's not clean, it was an easy  
> hack" copout :)

I'm pretty sure GHC, at least, already does type synonym folding for  
error messages.  I suspect the same or a similar mechanism could be  
used to resugar tuples for messages.

I also don't think it's a copout.  Set theory formulations of  
classical mathematics usually defines n-tuples using nested 2- 
tuples.  At least one constructive formulation of mathematics I know  
of defines n-tuples as nested pairs (the Coq theorem prover, which  
also provides syntactic sugar).  It's a nice clean inductive  
definition and effortlessly allows tuples of arbitrary length.

The copout (in my opinion) is the current system where tuples are  
defined up to some set n (64 in GHC I think -- the report only  
mandates 15), and if you want bigger tuples you're SOL.  Why would  
anyone ever use a 15+ tuple?  Well maybe you wouldn't, but perhaps a  
code generator would.  Or maybe a joy interpreter would.  etc.

More disturbing is the complete inability to write general functions  
over tuples.  You can't even play fancy typeclass tricks because  
tuple constructors are not related by the type system in any way --  
you have to do it the hard way each and every time by writing out  
various versions at different arities until you get tired of typing.   
Or, if you are a little more industrious, you can write a code  
generator.  Either way, your function can only be defined up to some  
fixed limit.  The only fully general solution is to use something  
like template haskell which 1) is overkill 2) has ugly syntax (sorry  
but it's true) 3) GHC only and 4) hard to learn.


Rob Dockins


> -- m
>
> On Feb 4, 2006, at 11:03 PM, Robert Dockins wrote:
>>
>> On Feb 4, 2006, at 7:56 PM, Pablo Barenbaum wrote:
>>
>>> An awkwardness in Haskell I would like to see solved in
>>> Haskell', is the fact that the behavior of tuple-like
>>> constructors must be either built-in or "limited".
>>
>> One thing I recall seeing on haskell-cafe some time back was the  
>> notion that an n-tuple is semantically equivalent to n nested  
>> right-strict 2-tuples (essentially right-strict heterogeneous  
>> lists).  Perhaps we should consider the idea of the tuple notation  
>> simply being syntactic sugar for nested right-strict 2-tuples.   
>> Consider:
>>
>> data Tuple a b = Tuple a !b
>>
>> -- (a,b)    === Tuple a (Tuple b ())-- (a,b,c) === Tuple a (Tuple  
>> b (Tuple c ()))
>> -- etc...
>>
>> fst (Tuple x _) = x
>> snd (Tuple x (Tuple y _)) = y
>>
>> fst ('a',b') = 'a'
>> snd (a','b) = 'b'
>>
>> fst ('a','b','c') = 'a'
>> snd ('a','b','c') = 'b'
>>
>> fst ('a','b','c','d','e','f') = 'a'
>> -- etc...
>>
>> It seems like compiler cleverness could recover the identical  
>> strictness and unboxing information available now when the "shape"  
>> of the tuple is known at compile time.
>>
>>
>>
>>> As far as I can see, these are two issues:
>>>
>>> 1. There is not a way, for the programmer, to define
>>> infinite constructors for infinite associated types (such as
>>> (,) (,,) (,,,) ... / (a, b) (a, b, c) (a, b, c, d) ...)
>>> these must be built-in.
>>>
>>> 2. There is not a way to define functions operating on all
>>> of these types. Instead, different functions (like zip,
>>> zip3) must be defined. Something similar happens with
>>> liftM, liftM2, ... these are "limited".
>>>
>>> It seems the language is lacking abstraction, or being
>>> misused, when the standard prelude issues this code:
>>>
>>>   zip              :: [a] -> [b] -> [(a,b)]
>>>   zip               = zipWith  (\a b -> (a,b))
>>>
>>>   zip3             :: [a] -> [b] -> [c] -> [(a,b,c)]
>>>   zip3              = zipWith3 (\a b c -> (a,b,c))
>>>
>>> Clearly, at least for a human being, it's redundant.
>>> I don't know if there already are proposals to solve this.
>>>
>>> Sorry if I sound aggresive, I'm just trying to help.
>>> Excuse my English...
>>>
>>> Best regards.