class (Ord (NodeIndex g) , Ord (EdgeIndex g) ) => Graph g where
type NodeIndex g
type EdgeIndex g
type NodeLabel g
type EdgeLabel g

But this has with it the problem of duplication of labeled and unlabeled version of functions, or the ignoring of () in representing unlabeled graphs.

Another avenue might abstract out this concept of labeling something. Along these lines?
class Labeled a where
type Label a
type Item a
label :: Item a -> Label a -> a

instance (Control.Functor.Zip a,Labeled b) => Labeled (a b) where
type Label (a b) = a (Label b)
type Item (a b) = a (Item b)
label = fzip

I just free hand wrote that, so i’m sure there are issues with it, but it seems that this labeled/unlabeled split causes so many problems. How about we try to separate that concept from the concept of a graph? A graph being just the structure. Then we can add labels to it.

From my experience with FGL I’ve always needed labels on my graphs, and in my opinion, even if you were only interested in the properties of the graph itself, the internal representation of the graph nodes (Ints with FGL) still essentially represent labels.

Additionally, my main frustration with FGL is the need to constantly handle the mapping between the Node (Int) and the labels and the associated reverse mapping. Having the label BE the node representation would simplify things greatly to my inexpert eye.

If you combine nodes into one node, there could be more attributes other than the label that need combining, so it would make much more sense to require a function for combining complete Nodes.

I have to agree with vivian, a graph library should not know anything about labels. (Your arguments all similarly apply to node color for example.)

Don’t get me wrong, this type of definition is very tempting. However, I think it involves too much work/compromise to be able to “scale”. Using graphviz for another example, specifically the GraphvizParams type. With the “labels are compulsory” specification, using it remains almost the same as it currently is. What’s more, you can then also change the underlying graph type and – as long as the label types remain the same – you can use the pre-existing GraphvizParams, etc. to visualise the graph.

However, if we go with your suggested layout, then every time you change your graph type, the transformation functions in the GraphvizParams change since there is no known structural layout that you can use: you can’t even tell if there _is_ a node or edge label! As such, functions such as these will become less generic and require more per-instance customisation because you can’t tell whether or not there is a label.

Another advantage of making usage of labels explicit and compulsory: sometimes you may be wishing to compact/collapse/etc. several nodes into one. If the presence of labels (and their types) are explicit, you can specify the requirement of a function that tells you how to combine them to form the new label. If you don’t know if there are labels or not, then creating a new node is much more difficult (another advantage of making the IDs abstract and distinct from the labels).

You don’t even need a way to differentiate between the ID part and the label part. Node identity is per Eq (or Ord) instance. And the label is extracted with the nodeLabel function in the LabelledNodesGraph class.

As there doesn’t have to be a specific ID part, making it completely abstract is then no problem either, that happens almost automatically.

However, if we make the overall node type part of the label, then we get duplication: say we have two nodes, (1,'a') and (2,'b'), where the first part of the tuple is the node ID and the second is the label. Using your proposed scheme, if I want to make an edge between them then I’d have to say something like: addEdge g (1,'a') (2,'b') "a to b".

So what happens here if I somehow accidentally instead did addEdge g (1,'c') (2,'b') "a to b" (i.e. the label for the first node is wrong)? Should the method accept it or fail? And whilst it might be more of an implementation rather than an interface/representation detail, but does this mean that the node label gets stored for every edge? Either way, this will result in more bookkeeping and more possible ways for things to go wrong.

Even if we can live with these limitations, I’m not a big fan of this style because rather than just using a tuple or some such, there is no standard way of differentiating between the ID part and the label part of the node and edge types. Instead, any time that you do want to deal with that overall node type, you have to customise how you do so depending on the instance involved.

Instead, I’m wanting to push towards making the ID type completely abstract. To see what I mean, see my current draft of planar-graph: users of the library cannot construct node IDs directly, and instead must “request” new such IDs by specifying what labels they want. If they are using a label-less graph, then defaults exist that use mempty for the label value.