[Haskell-cafe] Re: Re: Tuple-like constructors
robdockins at fastmail.fm
Wed Feb 8 14:22:07 EST 2006
[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-
> 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
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
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
More information about the Haskell-Cafe