<div dir="ltr">Hello all,<br><br>As Johan mentioned, here in Utrecht we are working on
libraries for generic programming. We want to make it easier for people
to use generic libraries, so we are packaging EMGM [1] and a library
for generic programming for mutually recursive datatypes [2]. We intend
to release these on Hackage soon (Summer vacations are delaying us a
bit), along with useful generic applications (a zipper and a generic
rewriting framework).<div class="Ih2E3d"><br>Maintaining SYB fits well in this idea, and if no other natural
maintainers volunteer, I (with some support from the other people at
Utrecht) am happy to take it upon me. I probably won't do heavy
development on the library, but including patches, and providing
support is fine. We're also planning to maintain EMGM here in Utrecht,
although we didn't develop that ourselves.<br>
<br>Recently, (at least) Claus and Oleg have been posting interesting
suggestions of improvements/modifications to SYB. Those should be
further analyzed and discussed, and finally introduced (or not) in the
library. The generic map for SYB, for instance, evolved from the
"impossible to implement", through the "unsafe implementation", until
the latest gmap2 as described by Oleg [3]. If further tests show this
function behaves as expected, then it's clearly a good candidate for
extending SYB. We should also rethink if other things previously deemed
impossible remain so.<br>
<br>Maintaining SYB, alongside with the other generic libraries, will require things such as:<br> * Releasing packages in Hackage, properly documented with Haddock;<br> * Updating such packages as necessary for new releases of GHC;<br>
* Writing examples of how to use the libraries (from a user perspective);<br> * Writing testsuites, which are important for checking backwards compatibility of any changes;<br> * Having an updated webpage linking to the library sources, documentation, possibly a bug tracker, etc.<br>
These are all things we plan to do for the libraries.<br><br></div>Additionally,
we could think of improving syb-with-class [4] in parallel with regular
SYB. This is something to ask to its maintainer.<br><br><br>Cheers,<br>Pedro<br>
<br>[1] <a href="http://books.google.com/books?id=OyY3ioMJRAsC&pg=PA199&sig=ACfU3U1nczeRAIjN9mc_vYnL1LnYAs70NA" target="_blank">http://books.google.com/books?id=OyY3ioMJRAsC&pg=PA199&sig=ACfU3U1nczeRAIjN9mc_vYnL1LnYAs70NA</a><br>
[2] <a href="http://www.cs.uu.nl/research/techreps/UU-CS-2008-019.html" target="_blank">http://www.cs.uu.nl/research/techreps/UU-CS-2008-019.html</a><br>[3] <a href="http://www.haskell.org/pipermail/generics/2008-July/000362.html" target="_blank">http://www.haskell.org/pipermail/generics/2008-July/000362.html</a><br>
[4] <a href="http://hackage.haskell.org/cgi-bin/hackage-scripts/package/syb-with-class" target="_blank">http://hackage.haskell.org/cgi-bin/hackage-scripts/package/syb-with-class</a></div>