Ivan Miljenovic wrote:
On 07/12/2007, Tommy McGuire <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
