[mercury-users] Event handling in mercury
Holger Krug
hkrug at rationalizer.com
Tue Jul 17 16:45:45 AEST 2001
On Tue, Jul 17, 2001 at 04:04:26AM +1000, Fergus Henderson wrote:
> On 16-Jul-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> > I don't think that's the right interface. The problem is that
> > once you've created a new mutvar you have to pass it around
> > *in addition* to the io__state in order to get at its contents,
> > which doesn't seem to be in the spirit of global variables.
You're right, the term "global" was not chosen carefully
enough. Better to say: State shared between parts of the program. My
experience shows that shared state is more important in practice than
global state. But for shared state there is no other way than "to pass
it around". For event handling code, which I had in mind, this has to
be done only once, when the callbacks are created.
> 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. 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 ?!
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.
--
Holger Krug
hkrug at rationalizer.com
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------
More information about the users
mailing list