[mercury-users] Re: Re: Some remarks and questions

[Ralph Becket]

Dominique de Waleffe, Wednesday,  7 May 2003:
> 
> In my view the most annoying thing if one does not go with the
> parallel grades, is that one cannot easily declare and maintain state
> information local to a given portion of the application. One has to
> export the state to the top level and pass it around all over. This
> goes against the modularity of your application.
> 
> If one goes to the parallel grade and thinks in the Erlang way, then
> one can encapsulate the state in the module definition and have the
> local state of a module maintained by a loop running in parallel to
> the application. The processes then can interact by exchanging
> messages, which, in Mercury, can be strongly typed.
> 
> Of course, going in that direction implies that one really starts
> thinking in terms of concurrency for designing the application/server
> and that is known to be difficult. 

One can compromise by writing each "portion" as a filter of the form

pred(MyMessageQueueIn, MyMessageQueueOut, MyStateIn, MyStateOut,
	OutgoingMessages)

and then just have a top-level scheduler pass control from one portion
to another.

This isn't such a bad way to write these things, but does require
careful design beforehand.

- Ralph
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------