[Moved to cafe; time to stop bothering the Haskell' committee...] On Feb 8, 2006, at 1:19 PM, Malcolm Wallace wrote:

Robert Dockins writes:

...

instance (Bin a,Bin b,Bin c,Bin d) => Bin (a,b,c,d)

See the problem? Sooner or later (probably sooner) I'll get tired of typing. I have to write down an 'instance' declaration for each value of n. Clearly this can't generalize to all n.

There has been a suggestion that the 'deriving' mechanism be de- coupled from the datatype declaration. Together with a generic default definition, that means you could write something like

deriving Bin for (,,,,,,,,,,,,,,,,,,,,)

and hence not need to write the tedious instance header yourself, since the compiler can easily infer it.

Humm. That is nice, and it would help keep my fingers from cramping, but it doesn't solve the root objection. Consider machine-generated code using largish tuples. Should the generated code include the 'deriving' clause? If no, someone from outside has to supply it. If yes, I have to deal with overlapping instance from other generated code. If maybe, I have to know when to generate it and when not. Solvable? yes, but kind of ugly. Acceptable? probably. Now, (speculatively combining a whole host of language extensions) if I could write down: deriving Bin for (_::*) Which would mean "derive (as necessary) Bin for all types at kind * where the suitable preconditions can be found/derived" I'd be completely happy. Humph. That's more or less adding an axiom schema to the constraint solving system of the typehecker which could be realized at link-time via C++ style template thingies or at compile-time by whole-program analysis. I am simultaneously appalled by and attracted to this idea..... Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG