Derive Ord for StateDiagram and UMLStateDiagram

[nimec01]

Is there any specific reason why these types are not deriving Ord?

Standalone deriving does not work since "The data constructors of ‘UMLStateDiagram’ are not all in scope"

[jvoigtlaender]

The short answer probably is that it wasn't needed so far. As in, there was no API use case for comparing diagrams. What is it you want to do? Put them in some collection data structure that needs order for efficient access?

A slightly longer answer is that simply deriving Ord (or Eq) would probably end up in a problematic place. The point being that the abstraction UMLStateDiagram hides that the underlying datatype has a field label that doesn't really have a meaning on the outermost level. This becomes apparent, for example, here:

sd-generate/src/Modelling/StateDiagram/Datatype.hs

Lines 139 to 146 in 278d13c

	rename :: (n -> m) -> UMLStateDiagram n a -> UMLStateDiagram m a
	rename f = unUML $
	\name substates connections startState ->
	umlStateDiagram $
	StateDiagram { name = f name,
	substates = map recurse substates,
	label = undefined,
	..

If a diagram output by that function would be passed to a derived == operation, a runtime error would occur.

So instead, Eq (or Ord) on UMLStateDiagram would have to be a custom definition that uses unUML and then progresses with the components except for label.

But the question really remains what the purpose of said Eq or Ord instance would be and what the correct semantics for that purpose would be. For example, in some instances in testing, one might want that == says two diagrams are equal if they only differ by consistent renaming of labels or rearrangement of substate lists. A derived instance would have a different meaning.

[nimec01]

I am currently using a Map with StateDiagram (standalone deriving works here). There was another case that required UMLStateDiagram to derive Ord, but that is not required anymore.

If a diagram output by that function would be passed to a derived == operation, a runtime error would occur.
So instead, Eq (or Ord) on UMLStateDiagram would have to be a custom definition that uses unUML and then progresses with the components except for label.

That makes sense. I will then define my own instance when necessary.