instance visibility

[Simon Marlow]

José Pedro Magalhães wrote:
> I'm trying to understand the implications of this discussion in the 
> current splitting off of SYB from base. In the division that was more or 
> less agreed [1], the Data class and its uncontested instances would be 
> kept in base, whereas the rest would go into a new syb package. The 
> instances were traditionally orphans in Data.Generics.Instances, but it 
> was suggested that they should now be moved into Data.Generics.Basics. 
> This would make SYB free of orphans, but no longer offers a user the 
> possibility of avoid the import of Data.Generics.Instances to define its 
> own instances. It also invalidates some of the changes proposed in [1], 
> namely caring about the imports of Data.IntMap, Data.IntSet, etc.
> 
> So my question is: should Data.Generics.Instances indeed be folded into 
> Data.Generics.Basics (which contains the Data class and associated 
> stuff)? (Worth noting is that the instances that are moved to the syb 
> package will remain orphans, but the idea is that those might change or 
> disappear in the future.)

My suggestion would be that yes, Data.Generics.Instances should be folded 
into Data.Generics.Basics.  If there are orphans to be moved to the syb 
package, then I think we ought to export the methods rather than defining 
instances, so that clients can define the instances themselves if they wish 
(although applications only, not libraries - a library would have to use a 
newtype).

This also means you don't have to break the API later by removing the orphans.

Cheers,
	Simon