can one_solution/2 and unsorted_solutions/2 be det?

[Don Smith]

Fergus wrote:

>This is exactly the problem which Mercury's support for committed choice
>nondeterminism was designed to solve.  

But it doesn't solve the problem in general, because cc_multi (cc_nondet)
predicates are not usable in all contexts where the feature is useful.
The programmer is forced to restructure the program so that the cc_multi
(cc_nondet) code is at the top level --- not within the scope of other
nondeterministic code.   For my program, it was most natural to call
unsorted_solutions/2 deep inside nondeterministic code.

Should the programmer be forced to make do without this (allegedly
non-logical) "feature"?  Or should the language theorists try harder to 
find a respectable semantics for it?       For the case of destructive
assignment, modern declarative languages allow the feature only within
single threaded code (using unique modes, monads, etc);  this too is 
painful sometimes.

Declarative languages are like stern, strict codes of ethics.

> For example, there might be two logically equivalent predicates (with 
> different predicate names) for which the solutions are computed in a 
> different order, yet the semantics says that the chosen solution must be 
> the same in both cases.

Orgun and Wadge claim that they avoid this pitfall by making choice
predicates first-order rather than second order.  Perhaps another way
to avoid it is to add an extra, distinguishing tag argument (e.g., a 
string representing the static syntactic call with arguments) to calls 
to choice predicates.

   Don (dsmith at cirl.uoregon.edu)