Data.Graph transitive closure

[David Feuer]

If we could boot it out of containers and into its own package, that would
make me happier; then I wouldn't have such a weird, special-purpose
structure sitting around in an otherwise general-purpose library.

On Mon, Jun 24, 2019, 1:38 PM Evan Laforge <qdunkan at gmail.com> wrote:

> 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
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190624/6417afe8/attachment.html>