Christian Maeder <Christian.Maeder@dfki.de> writes:
Ivan Lazar Miljenovic schrieb:
We considered giving it a new name (fgl', etc.) but figured that in the long term this wouldn't be advantagous. We feel that the situation is analogous to QuickCheck: when the new version came out most people kept using the old one until slowly the momentum shifted and more people started using the new version (without checking in depth, Roel's Hackage mirror reports QC-2.x now has 153 reverse dependencies as opposed to 127 reverse dependencies for QC-1.y).
If we changed the name, then the "emotional attachment" that the Haskell community has to FGL being the de-facto graph library means that people would keep using the old version. Whilst we also face the possible problems of people not liking the old version and thus automatically dismissing the new version, I think this is a much more unlikely scenario.
I'm afraid you'll destroy the "emotational attachment" to fgl by annoying incompatibilities (and possibly interfering new bugs).
Although parsec-3 can be used as an replacement for parsec-2 it would have been better, they had different names (as argued elsewhere for the haskell platform).
I'm sorry, I don't recall this discussion: care to summarise? With fgl, the actual changes aren't that big on the user side of things if they want to keep using the defaults (it's not a drop-in replacement, but the _way_ to use it remains unchanged). The big difference is when people want to make custom instances; however, as far as I know no-one has created any custom instances for FGL's classes.
Changing a dependency in a cabal file is a small problem. Those (unaware), who only mention "fgl", will fall over an incompatibility (usually at installation time!) and simple say "fgl < ..." unless they are willing to change their code then.
Those who already have "fgl < ..." need to find an advertisement of a "new and better fgl" anyway and can choose when to change their code.
But by keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. If, however, we re-use the package name then it will be more obvious that there is a new and (hopefully) improved version available. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com