[Hs-Generics] Re: Syb Renovations? Issues with Data.Generics

[Claus Reinke]

>>    My suggestion is to split this module into two, and stop the implicit
>>    import/export of the incomplete instances from Data.Generics.
> I don't think that this is a good idea.

Could you please elaborate on your reasons?

>>    Pro: - the instances are still available, and only one explicit import
>>                away, so 'deriving instance Data' for types containing
>>                uninteresting functions is still convenient
> But suppose you want to make such an instance in a library you write.
> Then you will import the instance, which means that it will be visible
> to all users of your library too, so they cannot define their own
> instance. Nor can they use other libraries that define their own
> instance.

True. But the current situation is even worse: we either get all
instances (good and bad) or none, and to get none, we'd have
to jump through hoops (not using Data.Generics, but importing
its component modules directly; and anyone trying to mix such
code with code importing Data.Generics is going to be in trouble).

There might well be a better way of making deriving happy, 
without such nasty side effects, but it will have to start with 
not having those faulty instances by default.

> I believe instances really do have to be global.

Instances are global. The only control we have are over the class
we define instances of and the type we define instances for. The
instances in question are of a non-local class, for non-local types,
so if they are implicitly imported, we're stuck with them.

The instances I don't want to be stuck with turn compile-time
errors into runtime errors for some methods, and violate nice
invariants for other methods.

Claus