<div dir="auto">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.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 24, 2019, 1:38 PM Evan Laforge <<a href="mailto:qdunkan@gmail.com">qdunkan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have been bit before by Data.Graph... I think it's that since it's a<br>
type synonym, it inherits Eq from Array, but it doesn't have a<br>
normalized form, so Eq is misleading in that topologically equal<br>
graphs are not Eq... something like that.  And it can't be fixed<br>
because it's just a type synonym over Array.  That's probably the "no<br>
attempt to add abstraction barriers" alluded to above.  But the reason<br>
I used it in the first place was I wanted a graph, and behold there is<br>
Data.Graph already installed.  So it's presence in containers gives it<br>
the impression of authority, but it's definitely not as well developed<br>
as the other types in containers.<br>
<br>
Since it seems like it can't be moved or made into a proper type<br>
without breaking things, we could at least have some caveats in the<br>
documentation, saying what it's appropriate for and what it's not.<br>
And maybe warning about that Eq thing.  So I guess I'm seconding the<br>
"just add documentation" suggestion.<br>
<br>
Also while I'm here it's weird and confusing how it silently<br>
re-exports Data.Tree...<br>
<br>
On Mon, Jun 24, 2019 at 4:02 AM Johannes Waldmann<br>
<<a href="mailto:johannes.waldmann@htwk-leipzig.de" target="_blank" rel="noreferrer">johannes.waldmann@htwk-leipzig.de</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> > I looked at doing this in a "principled" way a long time ago.<br>
> > I then got distracted by something else.....<br>
><br>
> You don't say :-)<br>
><br>
> Well, short-term suggestion (for containers:Data.Graph)<br>
> don't change existing code,<br>
> but improve documentation and do some benchmarking<br>
> <a href="https://github.com/haskell/containers/issues/648" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell/containers/issues/648</a><br>
> <a href="https://github.com/haskell/containers/issues/649" rel="noreferrer noreferrer" target="_blank">https://github.com/haskell/containers/issues/649</a><br>
><br>
> @David: perhaps you can label these issues as "nice to have"<br>
> so it does not look like "bugs that need fixing".<br>
> Benchmarking would make for a nice student project?<br>
> In fact, I will pitch this to my current class.<br>
><br>
> - Johannes<br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>