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

[Jonathan Morgan]

On 3/5/07, Peter Schachte <schachte at csse.unimelb.edu.au> 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.

If you prefer, a value !X should expand in some way to a !.X, !:X
(previous state, next state pair).  Your proposed change does not
maintain this, so it destroys the expected semantics.

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

I don't consider it equivalent.

> Instead I have to switch to a different language construct:
>
>         !:Position = position(7,42)
>
> which looks deceptively similar.  It's a sharp edge left left in the language
> for no good reason.  Sure, it's not a big enough sharp edge to really hurt
> yourself.  But still, why leave it there?

I don't see it as a sharp edge at all.  Instead, I would consider it a
sharp edge being able to write:

!:X = Term1, !X := Term2

There is something magical and undesirable about being able to do the
same thing in two different ways just be moving the `:'.  I would
prefer to limit the number of ways that an equivalent thing can be
done unless it leads to inconsistencies in the language.  In this case
I can see no inconsistency in the resultant language structure, so I
do not wish an additional way to do things which will probably be
unused (and certainly should not be used - we want to leave users with
the concept of unification, not assignment).  In addition, I think
that it is an undesirable sharp edge that `:=' can be used for
unification (a.k.a. assignment) when using state variables, but not
anywhere else.

In short, `:=' and record update syntax have a well-defined meaning
that makes sense.  Unification has a different and equally
well-defined meaning, and is logically distinct from record update
syntax.  To maintain the logical distinction between these two is
worth far more than correcting any alleged 'inconsistency'.

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