[Haskell-cafe] Re: Re[2]: Tuple-like constructors

[Robert Dockins]

[Moved to cafe; time to stop bothering the Haskell' committee...]

On Feb 8, 2006, at 1:19 PM, Malcolm Wallace wrote:
> Robert Dockins <robdockins at fastmail.fm> 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