Calligraphy in Haskell-summer-of-code

[lsmor]

Hi

I wrote a proposal for improving calligraphy as part of the haskell summer of code. The proposal focuses on substituing the current ad-hoc Graphviz builder for the graphviz package so we rely on well tested package instead of custom implementations.

What do you think about the proposal? are there better ways to improve the tool? Also cosider that this proposal was writen two months and a half ago. At that moment the tool seemed abandom. I see you are pushing again some commits.

[jonascarpay]

Hey, thanks for your interest, and for writing the proposal. Starting at the bottom,

At that moment the tool seemed abandom. I see you are pushing again some commits.

I'm glad to tell you that calligraphy is not abandoned at all, it's just more or less done. If people have specific requests/proposals I'm happy to work with them, though.

are there better ways to improve the tool?

My goals are (in order):

1. Keep it up-to-date with GHC releases. The biggest threat to and most common killer of GHC-based tools is losing pace with GHC development.
2. Modularize it into separate packages, especially the CLI and core library. Allow people to depend on just the parts they need, allow me to maintain just the parts I care about. For example, I'd like this project to look something like this:

flowchart 
  calligraphy --> ghc
  calligraphy-cli --> calligraphy
  calligraphy-gui? --> calligraphy-graphviz?
  calligraphy-graphviz? --> calligraphy
  calligraphy-graphviz? --> calligraphy-fgl?
  calligraphy-fgl? --> calligraphy

What do you think about the proposal?

The reason I did not put the CLI above calligraphy-graphviz is because the CLI is just not really the right place for super complicated graph manipulation. It currently already is tricky to get the graph that you want, and it's already collapsing under the number of options it has. None of those issues are helped by depending on graphviz or fgl, it just takes on dependencies that don't solve issues it currently has.

Instead, I think it's clear that ideally, we'd have some sort of GUI instead. The issue with that is that the design space is so large that I'm not actually sure how to go about that. Instead, I just want to be able to support other people's efforts as best I can, such as #9. I would be happy to use graphviz and fgl as parts of that effort, for dependencies to opt-in to.

Let me know if that makes sense, or if you have any questions.

CC @Kleidukos @considerate

[lsmor]

It makes total sense to me a modularization of the tool. Actually me original proposal for hsoc was to refactor calligraphy to split it in multiple packages, but that doesn't seem like a good enough proposal for hsoc.

[considerate]

@lsmor I agree with @jonascarpay that getting a GUI for this project should be a priority. However, this is obviously dependent on the calligraphy tool actually working so making sure that it works with the latest version of GHC should take precedence in my opinion.

Personally, I don't have a strong opinion about the structure of the Haskell packages.

As for the replacement of generating the graphviz output using the Haskell library compared to generating strings output in this library I'm cautiously in favor. I think that it might result in a more complex implementation though, so ideally having that kept in a separate package (calligraphy-graphviz) like @jonascarpay suggested, at least until it can replace all of the rendering functionality of the current CLI.

I think the kind of GUI provided in #9 would be nice, however, for that to be really useful I think that it should support features such as selecting a specific node as the root of the tree, expanding, collapsing and hiding subtrees and zooming into smaller areas in some interactive manner. Also, I think that the pure d3.js implementation is difficult to maintain so I was thinking of rewriting the visualizations using PureScript but never got around to doing that.

[lsmor]

Nice to have some perspective. Clearly the first step is to modularize the tool further. let me ask: both of you commented about "Keep it up-to-date with GHC releases". In the cabal file I see that it is already tested with the newest versions of GHC. I am missing something?

ping @Dmills27

[considerate]

@lsmor While calligraphy builds with the most recent GHC, it can’t parse and handle all call graphs generated by all of the GHC versions. Sometimes calligraphy will be nice and error out but at other times you might just get an incorrect call graph returned.

This is related to the philosophy and I’m not proposing that the tool needs to handle all cases to be deemed up-to-date. That said supporting generation of call graphs is a bit of a moving target because the HIE files differ between GHC versions.

Also, note the wording to “keep” it up to date, not to “make” it up to date with GHC. It’s very important to not lag behind too much because then no one will be able to use calligraphy.

[jonascarpay]

There's a reference Haskell file that contains most features people use on a daily basis (the biggest omission being TH), and CI makes sure that for every GHC version we render the same dot file. That sort of functions as a blessed set of features that we guarantee support for. When a new GHC drops, the game is essentially just to get it to a point where it correctly renders that dot file.

[ulysses4ever]

The link to the proposal in the original post is broken now (always use permalinks!). For posterity, the proposal can be found here: https://github.com/haskell-org/summer-of-haskell/blob/e2fa6468a2bc3cd54523d834bc715c53609306b2/content/ideas/improve-calligraphy.md