[mercury-users] Re: Handling a timer in Mercury

[Fergus Henderson]

On 06-Aug-1998, Bert Thompson <aet at cs.mu.OZ.AU> wrote:
> 
> If you simply want to implement ANSI standard C procedures time() and
> clock(), then Tom's quite correct. Of course, you're then obliged to
> single-thread the i/o state through your computations.

If the use of timers affects only the program's operational semantics,
not it's declarative semantics, then I suppose you could use committed
choice nondeterminism rather than threading an I/O state.

> On the other hand, if you're thinking of implementing something like
> the realtime timer procedures from POSIX.4, then that's a completely
> different barrel of bananas.
>
> The POSIX.4 timer procedures include timer_create() and timer_settime().
> (See man pages on a recent Solaris, frinstance.) They use signals and are
> entirely interrupt-driven. As far as I know, there is no neat way to
> mesh this with Mercury.

We haven't really thought about it too much yet.
If worst comes to worst, there's always the C interface ;-)
But signal handling is a form of concurrency, and we know how
to model concurrency in Mercury; I don't think we'll have too
much difficulty coming up with a Mercury interface to signal()
or sigaction().

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.