[Haskell-cafe] (automatic) type classes context inference

[Evan Laforge]

On Sat, Aug 28, 2010 at 12:22 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
>  i believe that a valid idiom is to define a class C that has no  functions,
> but requires  any instance   to also be of type classes A and B, so that you
> can write: C a => blah
> rather than (A a,B a)=> blah, though I don't know how often such is used in
> practice
> the same idea should apply more generally to multiparam type classes

I've done this.  It's handy not only for reducing class context noise,
but also keeping implementation details from leaking out the
interface.  It looks funny when some function randomly requires its
parameter to be Storable just because somewhere down the line someone
else needs it, and it's awkward when a whole interface requires the
same 4 typeclasses on every function.

Of course, if you want to write a new type that can be passed, you do
need to implement those classes, so from the point of view of that
user it's not an implementation detail.  But from the point of view of
someone just passing in data, not writing their own instances, it's
awkward to have to keep writing a random bunch of class contexts that
reflect the implementation of a function and may break if that
implementation changes.