🚀 go-pugleaf

In article <ganNChe00WB2QF5VM0@andrew.cmu.edu>, tg1e+@andrew.cmu.edu (Timothy R. Gottschalk) writes:
> run(Event_In):-                             % run takes a member of a special
>      call_eval(Event_In, Event_Out),        % domain as an argument.
>      Event_Out = done,!.                    % loop finished when symbol 'done'

> call_eval(Event, Event).
> call_eval(Event_In, Event_Done):-
>      exec_event(Event_In, Event_Out),       % SEE BELOW FOR exec_event***
>      call_eval(Event_Out, Event_Done).

I have no idea what Turbo (Latin for "I whirl around, make confused") Prolog
does with the heap here.  To be useful on a PC, a Prolog system has to have
a garbage collector for the heap, so you shouldn't have to worry.  (Try LPA
Prolog Professional or ALS Prolog instead.)

The code as shown is unduly complicated.  All you want to do is to keep
on calling exec_event/2 until it returns 'done'.  The following two
clauses do the whole thing:

	run(done) :- !.
	run(Event) :- /* Event ~= done */
	    exec_event(Event, NextEvent),
	    run(NextEvent).
		
If exec_event/2 is determinate, this is determinate.
If exec_event/2 is not determinate, this is not determinate.

> I want to reuse the same heap space since I won't need to ever backtrack.

It is precisely the business of the garbage collector to make this happen
without you lifting a finger.  If Turbo Prolog doesn't do it, work out what
your time is worth, and buy a PC Prolog that _does_ do it.

>    putting a cut in the first instance of call_eval
>    would be contrary to the idea of the repeat..fail.

But your program isn't *using* a repeat/fail loop.  It's doing recursive
calls to exec_event/2.  Don't get the two coding schemes muddled up!
-- 
The taxonomy of Pleistocene equids is in a state of confusion.