[Haskell] Re: Please check your dependencies on fgl

[Christian Maeder]

Ivan Lazar Miljenovic schrieb:
[...]
we don't need to repeat a parsec-2 vs parsec-3 discussion.
There are obviously different opinions that cannot be easily changed.

>> 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?

I guess, Data.Graph.Inductive.PatriciaTree wasn't available when I
created my own instance. Furthermore, I'm using more efficient functions
directly on the graph that are not available via the graph class methods.

> 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).

Sure, I can live with either way.

> 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'll rather wait and see how the new FGL will look like and then
consider if re-writing is worthwhile.

>> (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...

Well, looking at our simple ascii usage, I decided to copy the used bits
 from the sources (one package less and its dependencies, to worry about).

> 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.

For me it's no big deal, if you make a new package fgl6 or make a new
version fgl-6, because I'll stick to fgl-5.4.2.2 as long as I see fit.

Others may complain, if their old sources no longer compile because they
got fgl-6 instead of fgl-5 by whatever unintended circumstances.

> 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).

I think, sources should go on hackageDB as soon as possible to get early
feedback.

Christian