[mercury-users] Uniqueness modes etc

[Dr Mark H Phillips]

Hi again,

There is also a third approach I think: a monadic one.  Basically it
would be along the lines of either of the two previous ones except that
we package up the details of the state transitions into monads.

The generic procedure, instead of taking a normal pred parameter
along with an di-uo pair, would take an input monad parameter.  And
instead of yielding a changed state variable, the generic procedure
would yield a monad, which when "run" would produce the changed state
variable.

What advantages would there be in doing things this way?  It would
provide a valid way of hiding the explicit state transitions (while
still making explicit that a stateful process is being produced).  It
would also be taking the stateful-process-creation task and
abstracting it, thereby making it easier to reason about this task.
Furthermore it allows global alterations to the process to be more
easily made.

These are some of the benefits that the Haskell crowd are claiming
with the use of monads.  From my current perspective I don't see why
one couldn't use both uniqueness types/modes _and_ monads, but I'm
wondering what Mercury users think about this?

Is there monad support already in Mercury?

Cheers,

Mark.

On Mon, 2004-01-12 at 14:41, Dr Mark H Phillips wrote:
> Hi All,
> 
> Thanks for everyone's input on how best to "package up" a state-changing
> process for use in some other generic predicate.  Let me give my
> preliminary conclusions from the discussion.
> 
> It sounds like there are two reasonable approaches to my problem:
> 
> 1.  Use store variables to represent state.  To "package up" a
> state-changing process: first implement the process using mutvars
> and a store di-uo pair, then curry any mutvar references and make
> available the resulting predicate.  The generic procedure is then
> only able to modify states corresponding to these mutvars via the
> provided predicate, and hence is not able to modify states in an
> inappropriate way.
> 
> 2.  Create a new module to package up an abstract state together
> with predicates that may work with it.  This way the generic
> procedure can _only_ do state changing operations provided by
> the module, and hence cannot modify states in an inappropriate
> way.
> 
> Downsides to each approach:
> 
> 1.  Although the store passed to the generic procedure cannot be
> used to inappropriately modify the curried mutvar references, it
> can be used to create new mutvars and mutate the store in an
> unintended manner through these.  But this doesn't really matter
> because the generic procedure could create its own separate
> store and do much the same thing anyway.  The other issue with
> this approach which was raised by Zoltan is that it could be
> used to disguise the fact that IO was being performed.  I am
> still a bit unclear on exactly how much of an issue this is.
> 
> 2.  This approach requires the creation of a new module, not that
> big a deal but why do this if a library module will do?  Also,
> what happens if there are several different state-changing 
> processes which you want to package up and send to the generic
> procedure?  You could do all the packaging up in the one module,
> using a single new abstract state type, but this would provide
> generic with opportunity to do inappropriate manipulations.  
> Alternatively, each "packaging up" process could be given its
> own abstract type.  But this would mean that the generic 
> procedure would have to be fully generic in the state variables
> again --- defeating, I think, the protection against accidental
> I/O that this approach was supposed to provide.
> 
> In summary, my current perspective is that approach 1 wins.
> 
> Thanks for all the input,
> 
> Mark.
> 
> 
> --------------------------------------------------------------------------
> 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
> --------------------------------------------------------------------------

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