dot syntax escaping required for defaultStyleViaShow

[jmtd]

A Graph type's show implementation might generate strings that result in invalid dot output. For example

> putStrLn (export defaultStyleViaShow (path ["test \"1\"", "2"]) :: String)
digraph
{
  ""2""
  ""test \"1\"""
  ""test \"1\""" -> ""2""
}

or even

> putStrLn (export defaultStyleViaShow (path ["1", "2"]) :: String)
digraph
{
  ""1""
  ""2""
  ""1"" -> ""2""
}

Coincidentally the latter is legal Dot, but unexpected:

I think the legal characters for identifiers are [['a'..'z'],['A'..'Z'],['\200'..'\377'],"_"]

[snowleopard]

@jmtd Thanks! Indeed, this looks problematic.

Presumably, this is the right output?

digraph
{
  "\"1\""
  "\"2\""
  "\"1\"" -> "\"2\""
}

[snowleopard]

While this is being resolved, the workaround is to use exportAsIs after converting all vertex labels to strings using the right escaping. For example:

> putStrLn (exportAsIs (path ["1", "2"]) :: String)

digraph
{
  "1"
  "2"
  "1" -> "2"
}

[jmtd]

Hi,

Presumably, this is the right output?

Yep that's right.

While this is being resolved, the workaround is to use exportAsIs after converting all vertex labels to strings using the right escaping.

Very useful, thanks!

[jmtd]

This seems like a suitable piece of work for a beginner PR, so I am going to take a stab at this, however if anyone else wants to try it please don't let me stop you.

[snowleopard]

@jmtd Sure, please give it a try!

The main difficulty seems to be finding a way to escape characters without sacrificing the polymorphic interface. At the moment users can export into String, Text or any other similar datatype. How do we implement the escaping logic generically?

Perhaps, we need to define a type class of 'escapable strings' with a couple of standard instances:

class Escape s where
    escape :: s -> s

instance Escape String where
    escape [] = []
    escape (c:cs) = escapeChar c ++ escape cs
      where
        escapeChar :: Char -> String
        escapeChar c = ...

instance Escape Text where ...

For example, I found exactly the same solution here.

Then we'll need to strengthen the constraint on exportViaShow from Show s to (Show s, Escape s).

Does this make sense? Or is there a better approach?

[jmtd]

The main difficulty seems to be finding a way to escape characters without sacrificing the polymorphic interface.

You're right ,that's a detail I overlooked entirely when I first reported this (I subsequently came up with concatMap (\x-> if elem x badChars then ["\\",x] else [x]), felt pleased with myself, and thought all that was needed was plugging it into the right place).

Text.JSON.Escape

I don't know of a better approach; this looks reasonable but I'll do some looking around (probably Tomorrow) and see what else comes up.

[jmtd]

Sorry for the radio silence here, slow progress, my WIP (not PR-worthy yet) is here https://github.com/jmtd/alga/tree/escape-typeclass

[snowleopard]

@jmtd No problem, take you time :) Don't hesitate to send a draft PR -- happy to review and iterate.

[jmtd]

OK I'll open one (now :)) as I have something that works for the simple case above, but there's clearly more work to be done.

[jmtd]

A brief update. I thought it wise to look at what others had done already, and so I was reading through Data.GraphViz.Printing, in particular addEscapes (anchor in that link). The de-facto rules appear to be considerably different to the theoretical ones (I was surprised for example to see escLetters = Set.fromList ['N', 'G', 'E', 'T', 'H', 'L', 'n', 'l', 'r']. I wonder why they are escaped?)

I imagine that Data.GraphViz.Printing reflects the truth of the Dot format, but the real test would be whether dot accepts it. So I was considering writing a simple test harness that would attempt an export of a given escaped string and see whether dot complained or not, as part of developing a proper escape routine (and/or verifying the rules in Data.GraphViz.Printing)

[snowleopard]

@jmtd Good idea to check what others are doing!

I was surprised for example to see escLetters = Set.fromList ['N', 'G', 'E', 'T', 'H', 'L', 'n', 'l', 'r']. I wonder why they are escaped?

I guess if we have a string Hello\nWorld we don't want to mess with the \ but leave it as is? Not sure, this all is getting quite complicated ;)

Yes, we need to collect a dozen of examples/tests and make sure our translation agrees with dot.