1 Aug 08:36
Re: [Hs-Generics] Re: Owning SYB
From: José Pedro Magalhães <jpm <at> cs.uu.nl>
Subject: Re: [Hs-Generics] Re: Owning SYB
Newsgroups: gmane.comp.lang.haskell.libraries
Date: 2008-08-01 06:36:37 GMT
Subject: Re: [Hs-Generics] Re: Owning SYB
Newsgroups: gmane.comp.lang.haskell.libraries
Date: 2008-08-01 06:36:37 GMT
Hello all,
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).
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.
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.
Maintaining SYB, alongside with the other generic libraries, will require things such as:
* Releasing packages in Hackage, properly documented with Haddock;
* Updating such packages as necessary for new releases of GHC;
* Writing examples of how to use the libraries (from a user perspective);
* Writing testsuites, which are important for checking backwards compatibility of any changes;
* Having an updated webpage linking to the library sources, documentation, possibly a bug tracker, etc.
These are all things we plan to do for the libraries.
Additionally,
we could think of improving syb-with-class [4] in parallel with regular
SYB. This is something to ask to its maintainer.
Cheers,
Pedro
[1] http://books.google.com/books?id=OyY3ioMJRAsC&pg=PA199&sig=ACfU3U1nczeRAIjN9mc_vYnL1LnYAs70NA
[2] http://www.cs.uu.nl/research/techreps/UU-CS-2008-019.html
[3] http://www.haskell.org/pipermail/generics/2008-July/000362.html
[4] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/syb-with-class
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).
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.
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.
Maintaining SYB, alongside with the other generic libraries, will require things such as:
* Releasing packages in Hackage, properly documented with Haddock;
* Updating such packages as necessary for new releases of GHC;
* Writing examples of how to use the libraries (from a user perspective);
* Writing testsuites, which are important for checking backwards compatibility of any changes;
* Having an updated webpage linking to the library sources, documentation, possibly a bug tracker, etc.
These are all things we plan to do for the libraries.
Cheers,
Pedro
[1] http://books.google.com/books?id=OyY3ioMJRAsC&pg=PA199&sig=ACfU3U1nczeRAIjN9mc_vYnL1LnYAs70NA
[2] http://www.cs.uu.nl/research/techreps/UU-CS-2008-019.html
[3] http://www.haskell.org/pipermail/generics/2008-July/000362.html
[4] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/syb-with-class
_______________________________________________ Libraries mailing list Libraries <at> haskell.org http://www.haskell.org/mailman/listinfo/libraries
> 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.
Further discussion welcome, of course!-) And it isn't just about getting
fmap/traverse/.. from Data/Typeable, but also about reorganizing imports
of Data instances, and providing alternatives of everywhere/everything
that avoid traversals of irrelevant subterms.
A current snapshot of my code can be found here:
RSS Feed