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

[Bert Thompson]

|Jack Andrews, you write:
|> How does Mercury model the idea of a timer?  A timer has one state at a
|> given time, and a different state at another, with no apparent influence
|> from other parts of the system.
|
|Actually it does - the values of the timer depend on the state of the
|world. An appropriate interface might be:
|
|:- module timer.
|
|:- interface.
|
|:- import_module io.
|
|:- type time.
|
|:- pred get_time(time, io__state, io__state).
|:- mode get_time(out, di, uo) is det.

Actually, it really depends what you mean by a timer.

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.

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. Possibly use a `task' blocked on a message
stream waiting for an alarm message from a timer task?
With prioritised message queues, this might work ok. Tom would know best.

On the other hand, Mercury people often invent nifty ways of
incorporating apparently disparate and antagonistic constructs
into the language. Someone else probably knows better than I do.

Bert
-----------------------------------------------------------------------
bert thompson                                           aet at cs.mu.oz.au
department of computer science                  university of melbourne
-----------------------------------------------------------------------