[mercury-users] semidet vs unique updating

[Michael Day]

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

Very true, it doesn't say the queue is modified.

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

Right,

:- mode di :: unique >> dead.
:- mode mdi :: mostly_unique >> mostly_dead.

now suppose the existence of a "could_be_dead" inst. The meaning of this
fictitious inst is that the variable cannot be referred to if the call
succeeds, just like the dead and mostly_dead insts. However the variable
can still be referenced if the call fails, just like mostly_dead. However
rather than copying it surreptitiously from a trail or whatever, the
compiler just uses the original variable.

:- mode ci :: unique >> could_be_dead.

:- mode queue__get(ci, uo, uo) is semidet.

Now when compiling queue__get, the compiler must be satisfied that the
predicate either maintains the uniqueness and unclobberedness of the first
argument, or cannot fail once the uniqueness has been compromised or the
argument has been clobbered. The implementation of get using not_empty and
get_det that I presented earlier would pass these requirements.

I have no idea if any of this is *possible*, but I'm asking if it as at
all *reasonable* and within the spirit of the mode system and the way that
mode declarations are intended to be used. The could_be_dead inst seems
like quite a hack, but I do not understand the foundations of unique and
mostly unique modes well enough to consider them to be any more than
(useful) hacks either.

Michael

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