<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Jul 28, 2008 at 11:50 PM, Neil Mitchell <span dir="ltr"><<a href="mailto:ndmitchell@gmail.com">ndmitchell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi<br>
<div class="Ih2E3d"><br>
>> As you know, Claus has offered a somewhat-detailed proposal for changes to<br>
>> the SYB library (below). But I don't think that we have an active<br>
>> maintainer for any of the generic-programming libraries (esp SYB) apart from<br>
>> Uniplate. Then there's the related question of what generic-programming<br>
>> technology to promote for clients of the GHC API.<br>
><br>
> Thanks for raising this, Simon. I've actually been holding an email<br>
> summarizing several issues (not just performance of default traversal<br>
> schemes) that I'd like to see adressed in Syb (holding because the Syb<br>
> authors were/are away, and because my performance improvement experiments<br>
> are currently stuck on a<br>
> GHC optimization issue). I'll send that email separately now.<br>
<br>
</div>I think SYB would best be maintained by someone who does not already<br>
maintain some kind of boilerplate removal library. There are lots of<br>
experiments into GADT's and other mechanisms, but SYB1+2 is a very<br>
useful design point - and one that should be preserved.</blockquote><div><br>I agree that SYB1+2 is a useful design point and that improvements should not affect the basic functionality and design. A library with a different gfoldl would very likely change SYB significantly. However, I don't think that there is a problem with a person maintaining several generic programming libraries, as long as the maintainer effects changes/improvements on SYB conservatively.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think the<br>
maintainer should do three things in addition to general release<br>
management:<br>
<br>
1) Speed improvements, if possible<br>
<br>
2) API tweaks, maybe a few extra functions (universe equivalent would be nice)<br>
<br>
3) Make it work with Hugs - I've always been surprised that SYB<br>
doesn't work with Hugs, and I don't think its that much work.<br>
<br>
As a result of these points, I think Claus is probably the perfect<br>
person to take over as maintainer.<br>
<div class="Ih2E3d"><br>
> (a) it helps to have someone else to "blame"<br>
> when the consequences of gfoldl's type once again hurt my brain;-),<br>
<br>
</div>You can still blame those that went before - I don't think an SYB<br>
maintainer should be changing the type of gfoldl - its too<br>
fundamental.<br>
<div class="Ih2E3d"><br>
> (b) it is really frustrating to get so little interest in these issues,<br>
> well, we haven't even managed to start a proper discussion on any of the<br>
> lists<br>
<br>
</div>I am interested. I have starred your emails, and will respond in the<br>
next few days. I've been in a tent without electricity for the last<br>
few days!</blockquote><div><br>I would be fine with Claus as maintainer. As Johan mentioned, there are also people in Utrecht who are interested in contributing with development or even willing to take over maintainership if necessary. Probably it is best to let Johan&co say more on Thursday :).<br>
<br>On a personal note, I prefer to not volunteer as a maintainer of SYB since I have other personal priorities at the moment (focus on writing thesis, searching for jobs), which also explains my slow reactions to emails. <br>
<br>Cheers,<br><br>Alexey<br><br></div></div></div>