[Haskell] Re: Please check your dependencies on fgl

[Ivan Lazar Miljenovic]

Christian Maeder <Christian.Maeder at dfki.de> writes:

> Ivan Lazar Miljenovic schrieb:
>>> 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?
>
> http://www.haskell.org/pipermail/libraries/2010-March/013101.html

I've read through that thread, but I remain unconvinced.  First of all,
I think there are a few misconceptions raised there (e.g. the gitit
discussion is because John Macfarlane doesn't want to use Parsec-3 for
Pandoc because it used to be slow and because it isn't available in
Debian; this latter point shouldn't be a concern for most software
IMHO; secondly, if the documentation of the 2.x series was better, then
why not improve the documentation of the 3.y series?).

Maintaining Haskell98 compatability may be a valid concern (I don't know
how valid it is to most people, but I can see some people preferring
it).

_Why_ should a library remain fixed at a particular version (unless of
course you are convinced it is perfect)?  By creating a new package,
people will keep using the old version which will eventually bit-rot
rather than upgrading.

There are also a few other differences between the situations here:

* A lot more packages use parsec than fgl, such that the conversion
  process is more difficult (whereas for those packages on Hackage that
  use fgl, over half have already responded that they'll fix the
  dependency problem such that the version update won't be a problem).

* The most common reason given for not upgrading to parsec-3 was
  efficiency; we're going to work hard to make sure that the speeds are
  comparable if not better (since for the most part the data structure
  is the same, it's just the overall API that differs in terms of how
  function names, etc.).

* Many people liked parsec-2; the common opinion on #haskell, etc. seems
  to be that fgl is full of warts and many people (such as Cale) prefer
  to use one-off custom graph implementations (e.g. IntMap IntSet)
  rather than use fgl.  A lot of the changes we're making to fgl comes
  from taking into account what people don't like about the current
  layout of fgl.

>> 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).
>
> I usually don't want to make even small changes at installation time.

But this isn't an installation time change, it's a build/develop time
change.

>> 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.
>
> Well, I've created a custom instance:
> http://trac.informatik.uni-bremen.de:8080/hets/browser/trunk/Common/Lib/Graph.hs
> and our hets project is not a hackageDB package.

This looks very similar to what is currently called
Data.Graph.Inductive.PatriciaTree; is there any particular reason for
using your own custom variant?

One thing you may like from the new fgl: proper Show, Read and Eq
instances being available for graphs (since I know some people are
annoyed that fgl currently doesn't have any method of serialising the
graph for storage/transmission; so much so that someone has even
resorted to converting the graph to/from Dot format and using that for
serialisation).

>> 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.
>
> Your "incentive" would be a "small annoyance" for me since it would
> force me to  change the dependency to "fgl < ..." until I find time to
> test our code with the newer fgl version (without possible other
> changes).

It's a very simple change, however (and arguably you and everyone should
always use bounded dependencies anyway just in case of this kind of
problem).

Arguably, changing the code may involve more time to take into account
the new API.  However, we aim to have sufficient advantages to the new
version of fgl that people would _want_ to change.

> (I still haven't updated from tabular-0.1.0.2 to tabular-0.2.x, yet.)

Wow, considering that tabular-0.2.1.0 (the first in the 0.2.x series)
came out over a year ago and you still haven't upgraded is a little
surprising...

As a compromise, we might consider not uploading the new version of fgl
to hackage (or having the developmental version use a new name, similar
to how darcs has darcs-beta for testing releases) and get that package
deprecated and hidden once we're satisfied and make a formal release.

However, I envisage having the new version fully developed and out by
the end of the year (time permitting, etc.; I want to get the API right
the first time so we don't have to go through this argument again next
year :p).

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com