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