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

[Ian MacLarty]

On Thu, Aug 03, 2006 at 08:43:39PM +1000, Jonathan Morgan wrote:
> 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.
> 

It depends what you mean by 'natural'.  This may seem natural to an
imperative OO programmer, but it isn't natural in the context of
declarative programming.

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