Data/Typeable/Uniplate instances for GHC types
ndmitchell at gmail.com
Wed Jul 16 12:54:16 EDT 2008
> 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
> 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.
More information about the Cvs-ghc