Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site zuring.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!zuring!dik
From: dik@zuring.UUCP
Newsgroups: net.lang
Subject: Re: Recursion
Message-ID: <242@zuring.UUCP>
Date: Fri, 20-Sep-85 01:16:58 EDT
Article-I.D.: zuring.242
Posted: Fri Sep 20 01:16:58 1985
Date-Received: Sat, 21-Sep-85 05:53:21 EDT
References: <712@gitpyr.UUCP> <250@mot.UUCP> <55@opus.UUCP>
Reply-To: dik@zuring.UUCP (Dik T. Winter)
Organization: CWI, Amsterdam
Lines: 20
Apparently-To: rnews@mcvax.LOCAL

In article <55@opus.UUCP> rcd@opus.UUCP (Dick Dunn) writes:
(No, not really...)
>> Actually, it's not too bad.  You just set up an n-by-n Boolean matrix
>> where n is the number of subroutines under consideration and the
>> ij element is 1 iff routine i calls routine j.  Then take the
>> transitive closure by Warshall's algorithm.  1's on the diagonal of
>> the result indicate which routines are indirectly recursive.
>
>This only detects potential indirect recursion.  As (I think) has been said
>before, the facts that A calls B and B calls A do not together imply that A
>and B are mutually recursive (but only that they might be).
>
Furthermore, how do you decide which routine calls which?
The problem props up when pointers to subroutines and subroutines with
subroutine parameters are used.  You will have no knowledge of order
of assignment and use (where, when?).  So you will not see some
truly recursive routines.
-- 
dik t. winter, cwi, amsterdam, nederland
UUCP: {seismo|decvax|philabs}!mcvax!dik


Brought to you by Super Global Mega Corp .com