2008/6/27 Ivan Miljenovic :

C.M.Brown writes:

...

I have approx. 100+ source files and I was wondering if anyone has a tool that would let me see a visual call graph for the source files; i.e. a visual hierarchy of which module is imported by what, and so forth.

For my maths honours thesis, I'll be writing a tool to help people understand the relationships in their Haskell code. I'm hoping to have a visualisation component in there, but that's a relatively low priority.

Assuming I get it included, is there any features in particular you'd want to see in there? Note that if I do have it produce visualisations, they'll be static images as part of an analysis report rather than being interactive.

Just today I wished for something similar for this MATLAB code I'm maintaining... would be good to have a pluggable syntax definition so that it could be easily adapted for use with other languages. Jeremy

Assuming I get it included, is there any features in particular you'd want to see in there? Note that if I do have it produce visualisations, they'll be static images as part of an analysis report rather than being interactive.

I was just recently wondering about something like this. I'd like the ability to show individual module dependencies, and then to collapse modules in one package to just the package, so I could "zoom out" and see how the packages relate to each other. By "package" here I mean the "A" in "A.B, A.C, etc." It seems like it would be fairly simple to use Language.Haskell.Parse to turn a set of modules into a graph, and then something to massage that and give it to dot. It actually brings up a question about module discipline in general: At one point I wanted to have each package re-export its public modules and then sibling packages can only export the "package" module as some libraries do, but it got to be too much re-exporting bookkeeppiing and I didn't so much like symbols having multiple "homes", and most of all it was increasingly awkward to split packages into strictly higher level and strictly lower level relationships since this discipline means coarser granularity which means more trouble avoiding circular imports. So now I just import modules directly from their packages. I still have a general structure of higher, lower, and sibling packages though, so some kind of visualization would be handy to keep deps under control, look for packages and modules that could be split up for a clearer hierarchy, find good places to cut circular imports, etc. I've also thought I could move private modules in A to A.Private, so you can see that if you're importing X.Private.Y from a module that doesn't start with X. then something fishy is going on. How do other people approach this issue?

On Fri, Jun 27, 2008 at 11:39 AM, Claus Reinke wrote:

If you wanted to go down that route, try using 'ghc --make -v2' and translate that dependency graph to dot.

Also, if you want to get a quick 'n dirty list of which of your own files depend on which others, "ghc -M $main.hs" works quite well. I've had some success in the past shoving this stuff almost directly into the graph libraries and out to graphviz. Be warned that it fiddles with any file called Makefile in your working directory... Cheers, D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net

...

If you wanted to go down that route, try using 'ghc --make -v2' and translate that dependency graph to dot.

Also, if you want to get a quick 'n dirty list of which of your own files depend on which others, "ghc -M $main.hs" works quite well. I've had some success in the past shoving this stuff almost directly into the graph libraries and out to graphviz. Be warned that it fiddles with any file called Makefile in your working directory...

You can redirect the output of -M, but since it appears that you cannot combine --make with -fno-code, the incantation you want is probably something like: ghc -M -v2 -optdep-f -optdep depend Main.hs which gives you dependency output in two forms, a module-based one to stdout (-v2), a file-based one to file depend (-M -f depend): $ ghc -M -v2 -optdep-f -optdep depend TestGMap.lhs Glasgow Haskell Compiler, Version 6.9.20080514, for Haskell 98, stage 2 booted by GHC version 6.6.1 Using package config file: C:\ghc\ghc-6.9.20080514\package.conf wired-in package ghc-prim mapped to ghc-prim-0.1 wired-in package integer mapped to integer-0.1 wired-in package base mapped to base-3.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1 wired-in package template-haskell mapped to template-haskell-2.2 wired-in package ndp not found. Created temporary directory: C:\DOCUME~1\cr3\LOCALS~1\Temp\/ghc1564_0 *** Chasing dependencies: Chasing modules from: TestGMap.lhs *** Literate pre-processor: Module dependencies [NONREC ModSummary { ms_hs_date = Tue Jun 24 19:25:08 GMT Daylight Time 2008 ms_mod = main:BinTreeDatatype, ms_imps = [Data.Generics] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Tue Jun 24 19:35:32 GMT Daylight Time 2008 ms_mod = main:GMap, ms_imps = [Unsafe.Coerce, Data.Generics, BinTreeDatatype] ms_srcimps = [] }, NONREC ModSummary { ms_hs_date = Tue Jun 24 19:24:46 GMT Daylight Time 2008 ms_mod = main:Main, ms_imps = [GMap, BinTreeDatatype] ms_srcimps = [] }] *** Installing new makefile: *** Deleting temp files: *** Deleting temp dirs: $ cat depend # DO NOT DELETE: Beginning of Haskell dependencies BinTreeDatatype.o : BinTreeDatatype.hs GMap.o : GMap.hs GMap.o : BinTreeDatatype.hi TestGMap.o : TestGMap.lhs TestGMap.o : GMap.hi TestGMap.o : BinTreeDatatype.hi # DO NOT DELETE: End of Haskell dependencies Claus http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation...

Hi Ivan,

Assuming I get it included, is there any features in particular you'd want to see in there? Note that if I do have it produce visualisations, they'll be static images as part of an analysis report rather than being interactive.

I'd basically like to see a graph of the overall struture of a Haskell project: what modules import what, and so forth. This would be useful to show which modules are forming the core of a system say, and which modules are acting on the top layer. Hope that gives some insight... Chris.

Hi Jno,

I suggest that you have a look at HaSlicer, a (visual) Haskell slicing tool available online from http://labdotnet.di.uminho.pt/ HaSlicer/HaSlicer.aspx , developed by Nuno Rodrigues (nfr@di.uminho.pt).

Oh excellent, yes I'd forgotten about this, thanks. Chris.