[mercury-users] Event handling in mercury

[Fergus Henderson]

On 17-Jul-2001, Holger Krug <hkrug at rationalizer.com> wrote:
> On Tue, Jul 17, 2001 at 04:04:26AM +1000, Fergus Henderson wrote:
> > So to make this elegant, I've been thinking about a language
> > extension that would allow you to write
> > 
> > 	:- interface.
> > 	:- global foo = int.
> > 
> > 	:- implementation
> > 	foo := 42.
> > 
> > or something like that (probably you can think of a better syntax for it),
> > with the same effect as the code above.
> 
> Maybe better to use the term "static" than global, directly
> corresponding to mainstream e.g. Java terminology.

OK, that's probably a good idea.

> A nice thing, a
> module static mutvar, which could be public:
> :- module my_mod_a
> :- interface.
> :- static foo = int.  % my_mod_a__foo: public static mutvar
>  
> :- implementation
> foo := expr.
> 
> or even private:
> :- module my_mod_b
> :- interface.
> 
> :- implementation
> :- static foo = int. % my_mod_b__foo: private static mutvar
> foo := expr.
> 
> What is the typing and mode declaration for `:=' ? Is io_state
> accessible in expr ? I deem, it should be. But also when initializing
> the static mutvar ? If yes, then the order, in which the static
> mutvar's are initialized, matters, because the initializer of one
> static mutvar could access the value already assigned to another
> static mutvar, but only if the second mutvar already would be
> initialized. (And what to do with dynamic loading ? The initializing
> value could depend on when a module is actually loaded.) So I think it
> would be better, to make io_state not accessible in initializers ?!

Yes, I agree.

If you really need to access the io__state to initialize it, you
can always use a maybe(T) type or equivalent, e.g.

	:- type initialized(T) ---> initialized(T) ; uninitialized.

define the variable as `foo := no' / `foo := uninitialized',
and then initialize it in main/2.  That way it is up to
the programmer to deal with the order of evaluation issues.

> So one would have 2 different forms of `:=', one only used to
> initialize a static mutvar, the other to set it's value in io_state
> related operations.

Yes, in my example I was assuming that `:=' would just be used for
static initialization, and that if dynamic initialization based on the
io__state is required then you'd use `io_store__set_mutvar' to override
the static initializer.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------