<div dir="ltr">On Fri, Apr 24, 2015 at 10:23 AM, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25 April 2015 at 00:01, Henning Thielemann<br>
<span class=""><<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:<br>
><br>
> On Fri, 24 Apr 2015, Ivan Lazar Miljenovic wrote:<br>
><br>
>> Specifically, I have a pull request for fgl [1] to add Ord instances for<br>
>> the graph types (based upon the Ord instances for Data.Map and Data.IntMap,<br>
>> which I believe are themselves partially ordered), and I'm torn as to the<br>
>> soundness of adding these instances.<br>
><br>
><br>
> In an application we needed to do some combinatorics of graphs and thus<br>
> needed Set Graph.<br>
><br>
> Nonetheless, I think that graph0 < graph1 should be a type error. We can<br>
> still have a set of Graphs using a newtype.<br>
<br>
</span>This could work; the possible problem would be one of efficiency: if<br>
it's done directly on the graph datatypes they can use the underlying<br>
(ordered) data structure; going purely by the Graph API, there's no<br>
guarantees of ordering and thus it would be needed to call sort, even<br>
though in practice it's redundant.<br></blockquote><div><br></div><div>Not to endorse any particular decision on the topic of the thread, but I'd point out that there is no problem here from a technical point of view. The Graph API can export a function `compareGraphs :: Graph -> Graph -> Ordering` which uses the underlying representation, but not provide an Ord instance which uses it. Then a user of the library can use `compareGraphs` in an Ord instance for a newtype wrapper, or as an argument to functions like `sortBy`.<br><br></div><div>Regards,<br></div><div>Reid Barton<br></div></div></div></div>