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
_______________________________________________
Haskell-prime mailing list
[email protected]
http://haskell.org/mailman/listinfo/haskell-prime
