Data/Typeable/Uniplate instances for GHC types

[Neil Mitchell]

Hi

>  Might help if library author and user are related?-)

Yes :-)  I'd like to think that anyone can use Uniplate in a very
high-level manner, but someone other than me needs to argue that.

>  So far, I still think that SYB for GHC types is a good and necessary
>  first step. If adding Uniplate instances as well gives significant
> improvements in efficiency or convenience, I won't argue against.
>
>  We probably agree on that?

Exactly. I'd be against adding Uniplate instances at this point, since
if you import Data.Generics.PlateData, you will automatically get
Uniplate instances without any work.

> > Yuk, much better to have something which just works (TM) without these
> > hacks.
>
>  no hacks involved, just a minor variation on everywhere and
>  everywhereBut:
>
>    everywhereS :: GenericT -> GenericT
>    everywhereS f x
>        | isString x = f x
>        | otherwise  = f (gmapT (everywhereS f) x)

But about replacing all type variables in a big CoreSyn, there could
still be lots of redundant traversal. This is probably a good step
forward, but there are still lots of cases it misses. Uniplate takes
it much further, and its a big win.

>  Actually, the traversal schemes are fairly trivial, and reading the source
> of Data.Generics.Schemes can be enlightening. Only the underlying gfoldl,
> etc, and their types, are non-trivial.

For fixing b (everywhere on list) its not too bad, just a little bit
of foldr/build and continuations - the Uniplate thesis chapter can be
followed pretty closely. For fixing c (skipping redundant types) its
fairly complex but doesn't touch gfoldl, and most of the difficult
code can be stolen from Uniplate.

Thanks

Neil