[m-rev.] for review: state vars syntax sugar

[Julien Fischer]

On Fri, 26 Jan 2007, Peter Schachte wrote:

> Ralph Becket wrote:
>
>> What about running DCGs "backwards"?  We might want to do the same with
>> state variables.
>
> Touché!  And for the X>>dead mode, doesn't X have to be unique?

It makes sense for it to be dead, however the current implementation
doesn't complain if it isn't unique (which is almost certainly a bug).
Actually, in a funny way, it makes sense to be able to define the mode
X >> dead
where X is not unique, but not to actually use it anywhere.

> And there is also an implied mode, and the mostly unique versions.
>
> But they're still pretty orthogonal:
>
> Forward modes: 	 X>>Final, Initial>>X
> Backward modes:        Initial>>X, X>>Final
>
> For normal versions:   Initial=free
> For implied versions:  Initial=X
>
> Normal:                Final=X,
> Destructive:           Final=dead and X must be unique
> Unique:                Final=unique and X must be unique
> Mostly destructive:    Final=mostly_unique and X must be mostly_unique
> Mostly unique:         Final=mostly_dead and X must be mostly_unique
>
> If that covers all useful cases, how about this for a syntax:
>
>  !(X)                 means X>>X, free>>X
>  !destructive         means unique>>dead, free>>unique
>  !mostly_destructive  means mostly_unique>>mostly_dead, free>>mostly_unique
>  !input(X)            means X>>X, X>>X

I think !input(X) is badly named.  After all !input(free) is really just
(unused, unused).

>  !backward(X)         means B, A if !(X) means A, B

> So most of the time, the mode for a state var would just be !ground, or
> occasionally !destructive, which look pretty good to me.  Also note that if
> Mercury ever supports ui modes, then !unique means (ui, uo).

If these things are supposed to be for threading state then !unique
doesn't make sense, you shouldn't be able to update it, so what's the
uo bit for?

I have a few problems with the inst based proposal as it stands:

(1) it has a much higher syntatic overhead than the mode based one
     in which I only had to remember one piece of syntax; I now have
     to remember five or six new pieces.

(2) it isn't as future proof as the mode based one, it's eventually
     going to have be extendend to handle (mostly-)uniquness and
     subtyping, e.g !destructive(X) means unique(X) >> dead etc ...
     (or however we end up denoting that.)

In the end I think a better proposal would be to separate that
subtype and uniqueness apects as Mark suggested somewhere (on this
thread?)

(3) I cannot use the inst based syntax to encode a change of uniqueness,
     which is trivial to do with the mode based one, e.g.

   :- pred do_complex_op_and_make_unique(!foo::(in, uo)) is det.

   do_complex_op_and_make_unique(!Foo) :-
 	op_part1(!Foo),
 	...
 	op_partn(!Foo),
 	make_unique(!Foo),
 	do_more_stuff(!Foo).

Julien.