| 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.
An alternative viewpoint might be: do the simpler, more efficient, and easier-to-use thing (Uniplate) first; and if that proves insufficiently expressive, move on to SYB.
There seems to be some agreement about using SYB (and Uniplate via SYB) first, though, with several cases of people having modified their own GHC sources to get it.
I hope you all know about
http://www.cs.uu.nl/wiki/pub/Alexey/ComparingLibrariesForGenericProgrammingInHaskell/technicalreport.pdf Yes, a very useful resource, in particular the way that the similarities between the very different approaches are highlighted. Definitely recommended reading, though only a preparation for the intended development of a unified generics library. It is a pity that the mailing list ([EMAIL PROTECTED]) for that effort is so quiet. But we also know already that several claims in there are misleading, eg, SYB can do type-changing traversals, it can do fmap, and it seems it can also be roughly as fast as Uniplate over SYB. Valid issues have been raised (type-changing traversals are far from obvious, and not included in the existing libraries), and scary stories have been circulated (performance-wise, SYB seems to be the worst of the bunch in that library comparison above) but not supported by firm evidence (there are valid performance issues, but it appears that unoptimised SYB has been compared against optimised other libraries, without analysing the source of the inefficiencies, so it is not at all clear how big the effect of the intrinsic performance issues is). I'm not saying that SYB is the best solution (I'm somewhat partial to how Smash replaces runtime type checks with compile time checks, and I like the simplicity of Uniplate, and there are aspect of SYB that just drive me crazy sometimes;-), but I think it is the best we have right now, proven to be useful for many of the things we want to do, and not proven to be problematic for anything yet. Claus _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
