[m-dev.] for review: add promise_only_solution/1 to std_util.m

[Peter Schachte]

On Fri, Nov 06, 1998 at 12:57:47PM +1100, Fergus Henderson wrote:

> > To be complete, shouldn't there be versions of promise_only_solution
> > for nondet and multi preds as well?
> 
> (2)
> Any use of `promise_only_solution' on a nondet or multi proc is
> probably a performance bug, because it would be more efficient
> to push the pruning inside the definition of that proc.

I was thinking of cases in which certain constraints on a particular
call tell you that there is only one solution even though the regular
types don't, but there isn't a special predicate for situation.

Now that I think about it, there really should be wrappers for all of
these purposes:

	to promise there is at most one solution,
	to promise there is at least one solution, and
	to promise there is exactly one solution,

promise_only_solution is the first of these.  If you accept this,
maybe the better way to specify is with something like

    :- type detism_promise ---> det ; semidet ; multi.

    :- pred promise_determinism(detism_promise, pred(T)).
    :- mode promise_determinism(bound(det), pred(out) is cc_nodet) is det.
    :- mode promise_determinism(bound(det), pred(out) is cc_multi) is det.
    :- mode promise_determinism(bound(det), pred(out) is nondet  ) is det.
    :- mode promise_determinism(bound(det), pred(out) is multi   ) is det.
    :- mode promise_determinism(bound(det), pred(out) is semidet ) is det.
    :- mode promise_determinism(bound(det), pred(out) is det     ) is det.

and similarly for bound(semidet) and bound(multi) except that
bound(semidet) wouldn't have a mode for det, multi or cc_multi
preds and bound(multi) wouldn't have det or semidet.

Not that you'd want to implement all those modes right now.wq

> (3)
> Adding the extra modes would be quite a pain.

A /big/ pain, because you'd have to use the C interface to have
different source code for different modes.  That's why you wouldn't
want to implement all those modes right now.

> (4)
> Even if we did, the set of modes still wouldn't be complete;
> e.g. we should add `uo' modes, etc.

Oh, yeah, those should be there, too.  That'll double the number of
modes.

> (5)
> We'll probably replace it with a proper language builtin in
> the not too distant future.

Good news!


-- 
Peter Schachte                | The greater part of our happiness depends on
mailto:pets at cs.mu.OZ.AU       | our dispositions and not on our
http://www.cs.mu.oz.au/~pets/ | circumstances.
PGP: finger pets at 128.250.37.3 |     -- Martha Washington