Tuple-like constructors

[Mieszko Lis]

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.

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

-- 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.
>>
>> --
>> Pablo Barenbaum
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
>> http://haskell.org/mailman/listinfo/haskell-prime
>
>
> Rob Dockins
>
> Speak softly and drive a Sherman tank.
> Laugh hard; it's a long way to the bank.
>           -- TMBG
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://haskell.org/mailman/listinfo/haskell-prime