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