Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site bu-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!bu-cs!hen
From: hen@bu-cs.UUCP (Bill Henneman)
Newsgroups: net.lang
Subject: Re: Recursion detection
Message-ID: <656@bu-cs.UUCP>
Date: Fri, 20-Sep-85 09:11:38 EDT
Article-I.D.: bu-cs.656
Posted: Fri Sep 20 09:11:38 1985
Date-Received: Sun, 22-Sep-85 05:11:19 EDT
References: <712@gitpyr.UUCP> <250@mot.UUCP> <55@opus.UUCP>, <242@zuring.UUCP>
Organization: Boston Univ Comp. Sci.
Lines: 25

Judging from recent traffic, there seems to be an overwhelmingly popular
opinion that detection of recursion has to be done in the dumbest possible
fashion.  Yes, it is true that you can write a routine which would make
both errors of inclusion and errors of exclusion when trying to build a
call graph: it is equally true that you can build an editor with no command
to save the buffer, or a mail routine that will not send mail to the local
site.  

But you don't have to.

Compiled languages place restrictions on what the programmer can say.  LISP
may allow
			(go (read))
but this is disallowed in any compiled language I know: the set of possible
labels must be explicitly available.  Same with calls.

The point of the above observation is that, in every language I'm
familiar with, you can write a symbolic execution module to help build
your call tree without fear of running into a halting problem situation.
It takes a lot more investment in coding (you have to write a bunch of
simplification routines for assertions, etc.), but you can write a
recursion detector which is not quite as stupid as the netters assume.

					Bill Henneman
					Boston University


Brought to you by Super Global Mega Corp .com