Data.Graph transitive closure

[Evan Laforge]

I have been bit before by Data.Graph... I think it's that since it's a
type synonym, it inherits Eq from Array, but it doesn't have a
normalized form, so Eq is misleading in that topologically equal
graphs are not Eq... something like that.  And it can't be fixed
because it's just a type synonym over Array.  That's probably the "no
attempt to add abstraction barriers" alluded to above.  But the reason
I used it in the first place was I wanted a graph, and behold there is
Data.Graph already installed.  So it's presence in containers gives it
the impression of authority, but it's definitely not as well developed
as the other types in containers.

Since it seems like it can't be moved or made into a proper type
without breaking things, we could at least have some caveats in the
documentation, saying what it's appropriate for and what it's not.
And maybe warning about that Eq thing.  So I guess I'm seconding the
"just add documentation" suggestion.

Also while I'm here it's weird and confusing how it silently
re-exports Data.Tree...

On Mon, Jun 24, 2019 at 4:02 AM Johannes Waldmann
<johannes.waldmann at htwk-leipzig.de> wrote:
>
> Hi,
>
> > I looked at doing this in a "principled" way a long time ago.
> > I then got distracted by something else.....
>
> You don't say :-)
>
> Well, short-term suggestion (for containers:Data.Graph)
> don't change existing code,
> but improve documentation and do some benchmarking
> https://github.com/haskell/containers/issues/648
> https://github.com/haskell/containers/issues/649
>
> @David: perhaps you can label these issues as "nice to have"
> so it does not look like "bugs that need fixing".
> Benchmarking would make for a nice student project?
> In fact, I will pitch this to my current class.
>
> - Johannes
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries