... | ... | @@ -97,3 +97,10 @@ Since Ghc does support (standalone) deriving of `Data` and `Typeable`, it seems |
|
|
- [ gMap in SYB1](http://www.haskell.org/pipermail/generics/2008-July/000349.html), a technique based on `gfoldl`, `gunfoldl`, and some Dynamic types in the middle. Avoids `unsafeCoerce`, and uses the fact that the dummy instances are slightly more honest about `gunfoldl` than about `gfoldl`, but `gMap` cannot distinguish functor parameters from equivalent types (no `fmap`) and its type is too general for direct use (runtime type errors instead of compile time type errors)
|
|
|
|
|
|
- [ http://www.haskell.org/pipermail/generics/2008-July/000351.html](http://www.haskell.org/pipermail/generics/2008-July/000351.html), combining the advantages of the previous two techniques to define a `Data`-based `fmap`. The remaining uses of `unsafeCoerce` only distinguish the functor parameter type from equivalent types occuring elsewhere in the functor, so seem to be ok?
|
|
|
|
|
|
- **performance**: Syb traversals are sometimes associated with bad performance. Unfortunately, none of the anecdotes I'm aware of really investigates these performance issues in any detail (if you have useful data to add here, please do!). So I can only say here that
|
|
|
|
|
|
- there are various more or less obvious ways in which naive use of Syb traversal schemes can lead to very inefficient traversals
|
|
|
- until proven wrong, I'll assume that all of these traps can be avoided by careful tuning of traversal schemes!-)
|
|
|
- three example issues are listed in [ Data.Generics with GPS (using Maps to avoid getting lost in Data)](http://www.haskell.org/pipermail/generics/2008-July/000353.html), which also provides a generalisation of the main Uniplate `PlateData` (Uniplate over Syb) optimisation, in a form that can be used to address one of the performance issues of `everywhere` and `everything` (traversal of irrelevant substructures)
|
|
|
- I've been trying to address another of those three issues (too many runtime type checks), but am currently stuck because merely mentioning the necessary auxilary structures seems to disable some GHC optimisation, leading to a drastical loss of performance (as I'm not even using those structures yet, this might be a GHC bug? see [\#2463](https://gitlab.haskell.org//ghc/ghc/issues/2463)) |