This isn't strictly Haskell related, but anyway.
Next year I will be doing my honours in mathematics. One possible
topic for my thesis that I've thought of - and my supervisor is quite
enthused about - is to use graph theory to analyse various textual
sources, starting with source code but leavin
On 06/12/2007, Tim Chevalier <[EMAIL PROTECTED]> 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 a
On 12/5/07, Ivan Miljenovic <[EMAIL PROTECTED]> wrote:
> How I envisage it happening is that a parser would be used to find all
> "functions" in the given code, treat these as nodes in the graph and
> then use directed edges to indicate which functions call other
> functions.
aka a "call graph". T
"Tim Chevalier" <[EMAIL PROTECTED]> writes:
> aka a "call graph". This is called "control flow analysis" and the
> classic paper on it is Olin Shivers' dissertation
> This is very well-trodden ground, but if you familiarize yourself with
> the literature on the subject, then who knows, you may di
On Thu, Dec 06, 2007 at 09:34:30AM +0100, Ketil Malde wrote:
> "Tim Chevalier" <[EMAIL PROTECTED]> 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
This sounds like a fun project and it is certainly feasible to do. I
thought I'd give you some pointers to fun stuff that people have been
doing in the past.
Thomas Reps have been doing program analysis since the dawn of time,
but one paper that seems particularly related to what you try to do is
Ivan Miljenovic wrote:
How I envisage it happening is that a parser would be used to find all
"functions" in the given code, treat these as nodes in the graph and
then use directed edges to indicate which functions call other
functions. This resultant graph can then be analysed in various ways
s
On 07/12/2007, Tommy McGuire <[EMAIL PROTECTED]> wrote:
> > How I envisage it happening is that a parser would be used to find all
> > "functions" in the given code, treat these as nodes in the graph and
> > then use directed edges to indicate which functions call other
> > functions. This resulta
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
On 07/12/2007, Tommy McGuire <[EMAIL PROTECTED]> 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 referen
On Fri, Dec 07, 2007 at 10:16:43AM +1000, Ivan Miljenovic wrote:
> On 07/12/2007, Tommy McGuire <[EMAIL PROTECTED]> 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 w
11 matches
Mail list logo