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 _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
