[m-rev.] For review: State-variable record update transformation

[Julien Fischer]

On Mon, 5 Mar 2007, Peter Schachte wrote:

> Jonathan Morgan wrote:
>> This change is a syntactic sugar, done for convenience.  The syntax
>> you suggest provides no additional convenience, and does not strike me
>> as at all natural.  The reason why is exactly as Julien said: in
>> Mercury, the `!' operator is used to indicate an operation on the
>> current state to derive the next state.  Allowing !Var := Term as a
>> synonym for !:Var = Term destroys these semantics, as it completely
>> ignores the previous state.  I do not expect Mercury to work like
>> that, and I do not wish it to work like that.
>
> I can't see why you want to require yourself to use the previous value in
> setting the next, but anyway, you can't.  There are lots of ways I can replace
> the value of a state thread using only the !X (not !:X) notation.

What do you mean by "replace"?  If you mean replace without reference to
the previous state, no there are not that many ways.  Most usages of
state variables refer to the previous value of the state in some way.

> I always find it annoying when a construct is defined for one or more of
> something even though it makes perfect sense for it to work for zero or more.

I do not think it makes perfect sense.

> It just seems untidy and non-orthogonal that I can write
>
> 	!Position ^ x := 7,
> 	!Position ^ y := 42
>
> but not the equivalent
>
> 	!Position := position(7,42).

So whereas !Position usually denotes an expansion into !.Position,
!:Position (in some way) we now have the exception that when we see:

 	!Position := position(7, 42)

it actually means:

 	!:Position := position(7, 42)

(And since ':=' is just decomposing into '=' in the above goal, why
choose '!:' as opposed to '!.'?)

Furthermore, although

 	X := Y

is a syntax error,

 	!X := Y

is not.  And of course, as I mentioned in a previous post,
':=' is always used in conjunction with field accessors, except
in the syntax you are proposing.

I suggest that even if your proposal made the language more tidy
and orthogonal in one respect, it makes more untidy and non-orthogonal
in at least the three above.

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