[m-users.] ui modes

[Julien Fischer]

Hi Michael,

On Thu, 1 Aug 2013, Michael Day wrote:

> I would like to change store.get_mutvar to use ui modes, like this:
>
> :- func get_mutvar(io_mutvar(T), io) = T.
> :- mode get_mutvar(in, ui) = out is det.
>
> This seems to have entirely reasonable semantics, as get_mutvar always 
> returns the same result in the absence of updates to the io.state, and does 
> not change the effect of any other IO operation.
>
> The reason I want to do this is so that I can have read-only access to 
> mutable variables in semidet code and if statements.
>
> Generally, ui modes don't work. But for atomic dummy types like io.state they 
> seem to work well enough.
>
> However, I have hit a couple of issues. A predicate with multiple clauses 
> will bind the IO as ground and lose its uniqueness:
>
> blah([], _IO).
> blah([_|_], IO) :- get_mutvar(..., IO)

The issue with multiple clauses and ui modes is a known problem; things
should be fine if you write predicates with ui modes in their head as a
single clause.

> Whereas writing it as an explicit switch is fine:
>
>    blah(Xs, IO) :- ( Xs = [] ; Xs = [_|_], get_mutvar(..., IO) ... )
>
> This makes code a little more verbose. Also, "not" and implication bind the 
> IO as mostly_unique instead of unique:
>
>    not(blah(Xs, IO)) <-- mode error
>
>    blah(Xs, IO) => fail <-- mode error

Depending on exactly what the mode of blah/2 is -- presuambly (in, ui)
-- that looks lke a bug.

> Whereas writing it as an explicit if-then-else is fine:
>
>    ( if blah(Xs, IO) then fail else true )
>
> So ui modes still seem very fragile, which makes me nervous. But using them 
> for get_mutvar is enormously convenient compared to having to destructively 
> thread the IO state through absolutely everything.

We've been using ui modes with atomic dummy types very heavily in the
G12 platform for years; provided the thing with the multiple clauses
doesn't bother you too much they work well enough.  (We had less success
with the mui mode though.)

The other "problem" with them is simply the lack of library support for
them, e.g. once you start using them in anger you pretty quickly find
that you need variants of list.foldl that pass an additional ui paramter
to the closure etc.  (G12 has a library of such procedures, which I
think we could make available ...)

> Is it possible to improve the handling of ui modes for atomic dummy types 
> like this?

In general, not without re-implementing the mode analyser.  (Small
improvements to specific problems may be possible with the existing
analyser though.)

Cheers,
Julien.