[mercury-users] Uniqueness modes etc

[Dr Mark H Phillips]

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