Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

more flexible DOT importing #23

Open
brandly opened this issue Apr 18, 2020 · 0 comments
Open

more flexible DOT importing #23

brandly opened this issue Apr 18, 2020 · 0 comments

Comments

@brandly
Copy link
Contributor

brandly commented Apr 18, 2020

graphs are created with Kite and serialized/exported in DOT. a DOT file can be imported into a Kite graph i.e. a GraphFile is produced from DOT:

fromDot : Dot -> GraphFile
fromDot (Dot _ _ stmtList) =

i assume this is true currently, but any graph should be able to be exported into DOT and then re-imported, creating the same graph as before.

(graph |> toDot |> fromDot) == graph

however, it seems like DOT produced by other programs, despite describing some graph with nodes and edges, can get imported as any empty graph with no nodes or edges.

to guarantee all exported graphs can be re-imported, fuzz testing is probably a good approach. generate random graphs and make sure that toDot >> fromDot effectively does nothing.

if we have that guarantee, we can extend the fromDot functionality to handle a wider variety of Dot. i think the main issue is that Dot represents the syntax AST of a DOT file. nodes and edges can be described in a few different ways, and i think fromDot only looks for the places that toDot uses.

we've talked about #7 before. i think it's a good goal, but we can't guarantee that fromDot >> toDot is a no-op. we're definitely not producing the same String of Dot.

i'm mainly dumping my thoughts out here, because i think it's a really useful improvement, but i don't want to do it yet lol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant