Add Ord instance for CList

[Xitian9]

Add an Ord instance for CList, and some functions which calculate ‘allRotations’ allowing only certain multiples of rotations to be used. Useful for when the CList represents something with some symmetries, but not all rotations.

[Xitian9]

Obviously there's not a canonical ordering on CLists, but this is one of the two obvious ones I can see. I think it's useful to have some ordering defined: if people need another one for some reason, it can be implemented separately.

[jeremyjh]

I'm not sure it is appropriate at all. Where order is important to users
of a clist it is most likely insertion order that they care about. If they
need ordering on the data itself probably a different structure is a better
fit. Can you describe a use case for this?

On Monday, August 22, 2016, Xitian9 notifications@github.com wrote:

Obviously there's not a canonical ordering on CLists, but this is one of
the two obvious ones I can see. I think it's useful to have some ordering
defined: if people need another one for some reason, it can be implemented
separately.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#11 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFhjjQsQSeFBX53VjzaHNa0LwWiXHmpks5qilE1gaJpZM4Joc-D
.

[Xitian9]

I'm using a modified version of the planar-graph module, which uses clists for node edges. In my case, the planar graphs furthermore have coloured nodes, and can be coloured by planar graphs. The result is a tree of planar graphs.

In order to compare whether two such graphs are isomorphic, their nodes need to be ordered so that nodes of the same colour class are adjacent. I've implemented this using groupWith, which requires an ordering on node colours. Since nodes can be coloured by planar graphs, this requires an ordering of planar graphs, which in turn requires an ordering of the clists representing their edges.

I'm willing to believe that this need is specific enough that it need not be incorporated into the main library, but I thought I'd contribute it in case others found it useful.

[Xitian9]

I'll also clarify that this is not an ordering on the data contained in a clist, but rather an ordering of clists themselves: i.e. how does clist a compare to clist b.

Thinking of it the following way: a clist is an equivalence class of lists. If we have Ord a, then this implies Ord [a]. I think it's natural to want to lift this to Ord (CList a), but the problem is that you don't get a well-defined ordering, as choosing different lists in the equivalence class gives you different results.

This can be solved by choosing a rule which picks out a canonical representative of the equivalence class, and uses that to lift the ordering. Since we have Ord [a], there are two natural choices: the minimum and the maximum. In this case I've chosen to use the minimum, and that allows Ord (Clist a).

The other seemingly natural choice is to use the list returned by toList, but this is not a good choice, as we can then have a == b, but a compare b /= EQ.