[mercury-users] Re-ordering and getters/setters

[Jonathan Morgan]

On 8/3/06, Ian MacLarty <maclarty at csse.unimelb.edu.au> wrote:
> On Thu, Aug 03, 2006 at 02:48:19PM +1000, Jonathan Morgan wrote:
> > If I have a foreign type that is accessed with a getter, and can be
> > affected by various operations with side-effects hidden in the I/O
> > state, is it safe to use a non-IO getter, as the getter is guaranteed
> > not to affect the state of the object and would therefore be pure
> > without the IO state, or should both getters and operations on the
> > object take the I/O state, just to ensure that the getters and setters
> > happen in the expected order?
> >
> > It would seem to me that Obj^property is a much more natural way of
> > expressing things than object_get_property(Obj, Prop, !IO), so I would
> > prefer to use it, but only so long as it does not lead to unexpected
> > results due to re-ordering.
> >
>
> If I follow you correctly then your non-IO getter is in fact impure.  It is
> impure because you may get different results depending on where you call
> it even for the same inputs.

That is correct.

> Consider the following piece of code:
>
> set_property(Val0, Obj, !IO),
> A = Obj ^ property,
> set_property(Val1, Obj, !IO),
> B = Obj ^ property,
>
> A should equal B here, since they both equal Obj ^ property, but if Val0
> \= Val1 then this won't be the case (please correct me if I've
> misunderstood how your setter works).

Unfortunately this all makes perfect sense.  I prefer the getter
notation to a predicate taking the IO state, but it doesn't seem that
that works.  I was merely thinking that an operation must remain pure
if it doesn't affect the value of data, without considering what
happened if you called the operation multiple times with the 'same'
values.

> Think of your Obj as a key and the IO state as a map, you can't lookup
> the value associated with the key without the map.
>
> To remidy the situation you can either add the IO state arguments to the
> getter, make the getter impure, or make the setter impure and the getter
> semipure.

The other alternative is to use uniqueness and state-vars - but that
means that everything that may possibly affect the variables must use
state-var notation, which it seems to me is too high a notational cost
just to use getters in a more 'natural' way.

Jon
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------