Sadly, that's not good enough as a general approach. It only works on the static cases, not on ones that only show up dynamically. When you use this approach on some of those, it also rules out non-recursive stuff that has closed loops it will never actually follow. Those are potentially recursive but not actually recursive. Of course, those will also throw a pre-processor, so that is what you really need to detect here - the problem isn't really "recursion detection" at all. And with stack emulation that you might be able to do inside the toy language, you don't need to stay within the limits of the pre-processor anyway. (What is the toy language, by the way?) Here's an example of potential but non-actual recursion I came across once. You have a number of intercepting calls here and there, that drop status information into a sort of error handler. It reports the status, to console or to printer. But what if the anomaly shows up within console driving code or printer driving code? You make the calls have flags that indicate whether to output to console and/or to printer. That way you never get an error call handing its results on to the code that called it, so you avoid actual recursion - but the links between functions look recursive to a static analysis. Oh, my first thought on analysing the graphs was to see if the inverses of related matrices always existed; if there are loops, things related like the Leontiev matrix of economics don't always have inverses. PML.