[mercury-users] semidet vs unique updating

[Mark Brown]

On 17-Oct-2001, Michael Day <mikeday at bigpond.net.au> wrote:
> 
> > A better solution would be to simply return an extra boolean result
> > indicating success or failure.
> 
> That is:
> 
> :- pred queue__get(queue(T), maybe(T), queue(T)).
> :- mode queue__get(di, uo, uo).
> 
> Quite possible. I've only been kicking and screaming so much because it
> seems that I should be able to mix unique objects with semidet code. The
> declaration above is lying, or at least misleading, in that the queue
> appears to be modified regardless of the outcome,

You are reading more into the mode declaration than is there.  The mode
declaration says nothing about whether the queue has been modified.  In
fact it says nothing whatever about the relationship between the first and
third arguments -- this declaration would be perfectly consistent with a
clause that ignores the first argument and returns (unique) constant
values for the other two.

What the declaration _does_ say about the first argument is that there
is only one reference to it at the point of call, and that there is
nowhere that needs that reference after the call.  In particular, it
implies the reference will not be needed on backtracking.  Making the
call semidet would unfortunately contradict this.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------