[Haskell-cafe] Graph theory analysis of Haskell code

[Tommy McGuire]

Ivan Miljenovic wrote:
> On 07/12/2007, Tommy McGuire <mcguire at crsr.net> 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 <ketil+haskell at ii.uib.no> 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 at crsr.net