Hello,
On Tue, Sep 2, 2008 at 14:35, Ian Lynagh
FWIW, I don't believe in "dubious" instances.
Indeed not changing the instances is definitely still an option. Maybe it's best, for now, to focus on choosing a splitting solution which allows for all possible flexibility in the future development of SYB. After 6.10 is out, we then have all the proposed changes to SYB (including the dubious instances issue) analized and discussed before making the changes. I find Simon PJ's argument for keeping Data in base ("so that others can build on it without depending on the full glory of SYB") rather strong, and I guess any "interesting" change to the Data class would require a change in the internal deriving mechanism. I'm not saying that Data is perfect and should not be changed, but maybe it can be in base without fundamentally diminishing the oportunites for development in SYB. Do you agree with me, Claus? Also, I've just spent a couple of minutes staring at the SYB and
SBY-With-Class Data classes; am I right in thinking that neither can be implemented on top of the other?
I believe that is the case. syb-with-class is generally interpreted as another library for generic programming. Their interfaces differ (namely because syb-with-class requires abstraction over type classes, and since this is not possible it uses some trick). Could uniplate etc have been built on top of SYBWC's Data, instead of
SYB's Data? Is SYB's Data the basic building block only because there are more instances for it in the wild, and GHC can derive them?
I guess it could, but that would have implications on its usability. I guess SYB's Data is seen as a basic building block for generics because it's easy to use (and the automatic derivation plays a big role on that). Plus, it comes with GHC. A recent report compares various libraries for generic programming in Haskell and their expressiveness [1]. Thanks, Pedro [1] http://www.cs.uu.nl/research/techreps/repo/CS-2008/2008-010.pdf