On 06/12/2007, Tim Chevalier wrote:

This is very well-trodden ground, but if you familiarize yourself with the literature on the subject, then who knows, you may discover something new. And you can take pleasure in knowing that you've already independently conceived of an idea that lots of smart people have seen fit to put a lot of time into :-)

\o/ Yay! :p -- Ivan Lazar Miljenovic

On Thu, Dec 06, 2007 at 09:34:30AM +0100, Ketil Malde wrote:

"Tim Chevalier" writes:

...

This is very well-trodden ground, but if you familiarize yourself with the literature on the subject, then who knows, you may discover something new.

I'll just add that having a tool visualizing this would be very useful for refactoring code. If you e.g. use color to distinguish nodes/functions from different modules, you could use that information to decide to merge or split modules to minimize external interfaces.

You could also try to automatically cluster nodes, which would be more interesting theoretically, but IMO less likely to be practical.

Another option would be to couple this with profiling or coverage information to visualize something about the usage of paths and nodes in the call graph.

Indeed, a visualization tool like this would be cool! -- David Roundy Department of Physics Oregon State University

Ivan Miljenovic wrote:

On 07/12/2007, Tommy McGuire wrote:

...

It just occurred to me that this idea is more general than the control or data flow analysis that are the focus of similar ideas I've seen before. For example, you could trace type usage through the code (which would likely be a subset of the control flow for Haskell, but an interesting subset nonetheless). :-)

While I'd like to do this, for the purposes of ensuring that the project contains enough mathematics (and to keep my supervisor happy, since he is skeptical about why I keep bringing Haskell into everything, even though I've re-implemented in Haskell a program that he wrote in C which generated more/better answers, and we _still_ can't find where the bugs in his code are, but that's another story...), I'm not sure if I can delve too deeply into Haskell-specifics. Of course, if I can somehow turn the type usage into nodes on the graph, then that should be all right! :D

I was actually thinking that something like that would be more valuable for a language like C, where types are not represented in the control flow. By the way, in a completely different context I just ran across a couple of references: "Concrete Architecture of the Linux Kernel". Ivan T. Bowman, Saheem Siddiqi, and Meyer C. Tanuan. "Conceptual Architecture of the Linux Kernel", Ivan T. Bowman. (The first is available on CiteSeer; I haven't found the second.)

On 06/12/2007, Ketil Malde wrote:

...

I'll just add that having a tool visualizing this would be very useful for refactoring code. If you e.g. use color to distinguish nodes/functions from different modules, you could use that information to decide to merge or split modules to minimize external interfaces.

You could also try to automatically cluster nodes, which would be more interesting theoretically, but IMO less likely to be practical.

Another option would be to couple this with profiling or coverage information to visualize something about the usage of paths and nodes in the call graph.

This is partially what I was hoping to do. I do know that my supervisor was interested in examining C code and attaching cost information to the nodes (using some Unix profiling tool which he couldn't remember the name of),

prof and gprof?

but I'm not sure how I'd go about adding compilation and profiling into such a program.

-- Tommy M. McGuire mcguire@crsr.net

On Fri, Dec 07, 2007 at 10:16:43AM +1000, Ivan Miljenovic wrote:

On 07/12/2007, Tommy McGuire wrote:

...

I was actually thinking that something like that would be more valuable for a language like C, where types are not represented in the control flow.

By the way, in a completely different context I just ran across a couple of references:

"Concrete Architecture of the Linux Kernel". Ivan T. Bowman, Saheem Siddiqi, and Meyer C. Tanuan.

"Conceptual Architecture of the Linux Kernel", Ivan T. Bowman.

(The first is available on CiteSeer; I haven't found the second.)

OK, thanks.

...

prof and gprof?

That looks like them. Of course, us Haskellers have no need of such things, since our programs have profiling inbuilt into the RTS (at least when using GHC, anyway)!

prof derives most of its utility from special hooks baked into gcc and libc. So gcc/prof is not really that different from ghc/hp2ps. Stefan