Tuple-like constructors

[Robert Dockins]

On Feb 6, 2006, at 7:49 PM, John Meacham wrote:

> A much bigger problem is that treating n-tuples as nested 2-tuples
> doesn't actually let you treat them generically, which was the  
> point of
> the proposed transformation.

I'm not sure what you mean here.

> imagine you want to replace all the values in an n-tuple with zero,  
> what
> type would it have?
>
> zero_out :: (Int,?) -> (Int,?)
>
> there is nothing you can put there which will let zero_out work on
> arbitrarily deep tuples, its recursive call will always need to be
> called on something of the appropriate type which means the nesting
> depth needs to be specified in the type signature.
>
>
> You can do something with classes, but then you might as well just use
> the class for general n-tuples.

Right, you can do something with classes; that's my whole point.  In  
haskell as it stands, you can't even express this function (or more  
properly, family of functions), short of using TH.

With this proposal (and MPTC) you could write:

class IntTuple x where zero_out :: x -> x

instance IntTuple () where zero_out = id
instance (IntTuple x) => instance (Tuple Int x)
    where zero_out (Tuple _ x) = Tuple 0 (zero_out x)


Yes the types are a little scary.  Typeclass programming like this  
isn't for the faint of heart.  However, the complete inability to do  
it can be pretty painful.  Witness the QuickCheck Arbitrary class,  
the Data.Generics.Data, Data.Monoid.Monid, and the Data.List.zipX  
family of functions for instances where the inflexibility of tuples  
causes arbitrary and unnecessary limits.


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG