[Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl

[Ivan Lazar Miljenovic]

Oh, great, the email _did_ go out on the mailing lists (what with
haskell.org being down I wasn't sure it would).

Don Stewart <dons at galois.com> writes:

> ivan.miljenovic:
>> Thomas Bereknyei are currently re-writing fgl (just about completely
>> from scratch) and we plan to make an initial release to get feedback
>> on the API in the next few weeks.
>> 
>> However, I'm sending this email out now to warn people that I highly
>> doubt any code that was written for the current version of fgl
>> (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the
>> new version.
>
> How about you give the library a different name then -- so as not to
> break all those programs?
>
> A complete rewrite with a new maintainer: fgl-awesome

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.

The overall philosophy is remaining the same: we're just updating the
implementation (letting people pick the Node type rather than
hard-coding it to Int, letting people constrain the label types and also
providing more scope for optimisations).  As such, the new version is
incompatible with the old one; however, if you're only _using_ FGL (as
opposed to making a new instance of the graph types), then the actual
changes to using the new version should be minimal (especially if you're
using it internally in which case you can hard-code the various types in
and not have to worry about the type family usage at all).

As I said, I've directly emailed the maintainers of the packages that
have open-ended dependencies on FGL and thus would have compilation
problems when we release the new version[s]; 7 out of 12 of those
maintainers have already responded within less than 24 hours so I don't
think this is likely to be a problem unless some new package is uploaded
in the near future without proper ranged dependencies.

So as to give you even more of a heads up, here are some more overall
plans Thomas and I have for FGL:

* FGL will still focus on inductive graphs; however the two current
  classes are being combined since it doesn't make much sense in general
  to have a graph that can be decomposed using match but can't be
  composed using & (there might be specific cases where this is true
  such as considering the Cabal package dependency "graph"; however this
  is likely to be defined internally within some project so users should
  just be careful about how they use it to ensure they don't add
  arbitrary nodes/edges that don't make sense; note that the new Show
  and Read instances take advantage of this by using Contexts as the
  basis of this instance).

* The ability to have proper Eq, Show and Read instances for graphs with
  pre-defined helper functions implementors can use (currently
  Data.Graph.Inductive.Tree has a "pretty" output for Show but no Read
  instance, and graphs cannot have equality due to overlapping instance
  problems).

* Splitting the library up into the base classes + sample instances (the
  fgl package) and a separate fgl-algorithms package (analogous to Dan
  Doel's vector-algorithms; this will be comprised of what is currently
  in the Data.Graph.Inductive.Query.* modules as well as the
  Data.Graph.Analysis.Algorithms.* modules in my Graphalyze library.
  The Data.Graph.Inductive.Graphviz module will also be scrapped in
  favour of my graphviz library.

* By default, fgl will ship with two default instances: the one
  currently in Data.Graph.Inductive.PatriciaTree and also a generic
  Map-based one that lets people choose their own Node type (i.e. the
  key type in the Map).  Any other suitable instances that we can think
  of (e.g. Thomas has the beginnings of a vector-based one) we'll ship
  in separate packages (e.g. fgl-vector).

If anyone has a good reason to object to any of these plans, we are
willing to be persuaded out of them.  This is why the 6.z series of fgl
will be "technology previews" to slowly build up what FGL does and gauge
the reaction of the Haskell community.

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