Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!ucsd!ucbvax!mlpvm1.iinus1.ibm.com!ludemann
From: ludemann@mlpvm1.iinus1.ibm.com ("Peter Ludemann")
Newsgroups: comp.lang.prolog
Subject: Demons in Prolog
Message-ID: <9012041847.AA01647@ucbvax.Berkeley.EDU>
Date: 4 Dec 90 18:47:33 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 38

alan@nereid.jpl.nasa.gov (Alan Quan) asks:
> I need to find out if it's possible to implement demons in
> Prolog in an efficient manner.

The answer is "yes".  IBM-Prolog has such a construct.  I
won't bore you with all the details (there are 16 pages in the
Programmer's Guide plus a few in the Reference Manual).  In
essence, you can define three kinds of interrupts:

    1. Wait on a variable to become instantiated.
    2. Do not restore the initial state and allow choice points.
    3. Restore the initial state and remove choice points after
       the interrupt finishes.

The first kind is essentially the freeze/2 predicate.

The other two are used to implement things such as the
equivalent of control-C (stop execution).  Each external
interrupt has a predicate associated with it (by the "dec_it"
declaration), an interrupt level (this can be used to mask out
low priority interrupts), whether or not it can interrupt
compiled code, and a "type" which indicates whether the
failure in the interrupt predicate will cause failure in the
currently executing goal (that is, whether or not the
execution and backtrack stacks are restored after the
interrupt predicate finishes).  An interrupt can do any
side-effects, including changing the internal database or
raising error condition ("stop execution" simple causes a
"stop execution" error which, like all other errors, can be
trapped by the Prolog program).  The debugger is also
implemented with an interrupt mechanism.

The efficiency of interrupt handling depends mainly on the
operating system; with the right kinds of operating system
features, the implementation inside Prolog is very simple and
efficient (sorry, I can't provide details).

 - Peter Ludemann      ludemann@mlpvm1.iinus1.ibm.com


Brought to you by Super Global Mega Corp .com