Stephen Tetley
What would your thoughts be on freezing FGL as it is and putting changes into a new package "FGL2" or "NewFGL"?
That's another possibility. However, I was planning on keeping the fundamental layout and design of FGL. I quite like and have used the inductive approach of graph construction/deconstruction in my own code; I just plan on updating/modernising the layout and design (after all, large all-in-one packages are _so_ pre-Hackage :p). Whilst freezing it is an option, I feel that this will lead to the same problems that we already face with mtl: most people agree/know that the approach/design is bad, but we keep using it because there's no (one) viable alternative to be used (and thus mtl stays in the Platform, which means more people use it, and thus we have this vicious cycle). By using the same name we can break this cycle: there is no implicit "loyalty" to an old package that people still use because its familiar (of course, this leaves it open to the problems with QuickCheck and Parsec, yet they are being resolved and more and more people are moving to QuickCheck-2 and Parsec-3).
The implementation technique for FGL is independently interesting; Martin Erwig expanded on it in other papers ('Metamorphic Programming') but no one else seems to have picked up on it. As I think there is more mileage in the idiom and hopefully someone will pick up on it at some point, it would be nice if it survives in the code.
Hmmm.... I haven't come across "Metamorphic Programming" before, will have to have a read through it (which isn't that appealing at the moment, since I'm in the middle of the literature review section of my PhD :s). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com