Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!ncar!noao!arizona!debray From: debray@arizona.edu (Saumya Debray) Newsgroups: comp.lang.prolog Subject: Re: Tail Recursive loops <-> Failure Driven loops Message-ID: <5394@megaron.arizona.edu> Date: 7 May 88 14:22:37 GMT References: <2467@mandrill.CWRU.Edu> Organization: U of Arizona CS Dept, Tucson Lines: 34 Summary: transformations In article <2467@mandrill.CWRU.Edu>, arun@mandrill (Arun Lakhotia) writes: > In particular I am curious about, Debray's comment: > > It's not too hard to automate the transformation from tail-recursive > > loops to failure-driven loops ... > > Intuitively speaking: At the termination of a failure-driven loop, > variables bindings performed during the execution of a failure-driven > loop, are eventually lost (due to failures). However, those done in a > tail-recursive loop remain, if the loop terminates successfully - > deterministic or not. It would be nice, thus, to know how > tail-recursive loops can be transformed to failure-driven loops, > *** without using any side-effects ***. I don't know of any transformation of this sort that, in the general case, doesn't use side effects _somewhere_. The point is that the user's code is tail recursive, and hence (hopefully) free of side effects. When this is transformed to a failure-driven loop, side effects are introduced, precisely for the reason you mentioned: for saving and restoring argument values. But this is transparent to people who're trying to read and/or understand the program. References: - S. K. Debray, "Program Transformations for Failure Driven Space Reclamation in Prolog", TR 85/32, Dept of Computer Science, SUNY at Stony Brook, Dec 1985. - S. K. Debray and D. S. Warren, "Towards Banishing the Cut from Prolog", manuscript, 1987. -- Saumya Debray CS Department, University of Arizona, Tucson internet: debray@arizona.edu uucp: {allegra, cmcl2, ihnp4} !arizona!debray