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

Ian MacLarty maclarty at csse.unimelb.edu.au
Thu Aug 3 16:54:38 AEST 2006


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.

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

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.

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



More information about the users mailing list