[Haskell] Re: Please check your dependencies on fgl

[Ivan Lazar Miljenovic]

Christian Maeder <Christian.Maeder at 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 at gmail.com
IvanMiljenovic.wordpress.com