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

[Jonathan Morgan]

On 04/08/06, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> On Thu, Aug 03, 2006 at 08:43:39PM +1000, Jonathan Morgan wrote:
> > >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
> >
> > 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.
>
> Aside from the fact that pred declarations have to show two arguments
> where the clauses for it and calls to it show only one, I don't see
> how state var notation is any notational cost.  Using that would save
> you from having to thread the IO state everywhere.  Or, alternatively,
> it saves you from having to pass two arguments to thread the data
> through your code.
>
> One little enhancement, discussed recently on this list, would allow
> you to write
>
>     !Obj ^ property := Val0,
>     A = !.Obj ^ property,
>     !Obj ^ property := Val1,
>     B = !.Obj ^ property,
>
> Which looks more natural to me than the code you wanted to write
> above.

It does.  However, consider a data structure like a widget.  Many of
the calls that I make that set a property of the widget will also
affect the state of the world (often it will cause the widget to
re-draw itself).  I would assume that these changes should be
encapsulated in the IO state, as we are doing IO, rather than being
encapsulated in the data structure itself being unique.  This being
the case I would want all operations except getters using the IO
state, so it is less of a notational inconvenience making all the
getters use the IO state than making all the setters take the IO state
and use state-vars for the structure.

In short, I like the syntax (it looks nearly imperative), but I don't
think it fits in situations where the setters are causing IO to be
done, rather than just affecting their own state.

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