[m-dev.] call for opinions on promise_same_solutions syntax

[Zoltan Somogyi]

On 28-Feb-2006, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> Let me see if I understand this right.  You've got some (possibly
> compound) nondet goal p(X) and another (possibly compound) nondet goal
> q(X,Y),

No, for several reasons. First, the motivating p(X) for this whole exercise
is the deconstruction of a value of a type with user-defined equality.
That means it is not nondet; it is cc_multi, and no multi version is available
or can be made available. Second, I am arguing that p(X) cannot be compound,
and that if we do allow p(X) to syntactically be a conjunction of calls or
unifications, then that is just a shorthand for there being a separate 'p'
for each conjunct.

> and what you want to say is that although p may produce many
> non-equivalent bindings for X, each of them will result in the same
> set of solutions for Y?

Yes.

> So you can't say that the solutions for X are
> equivalent, but as far as Y is concerned, they are (so it's OK to
> commit to the first solution for X).

Yes.

> If that's the general case, how about just generalizing
> promise_equivalent_solutions?  You could say that
> 
> 	promise_equivalent_solutions Vars Body
> 
> means that every solution for every element of Vars entailed by Body
> determines the same set of solutions for all other variables that
> escape Body (ie, variables appearing both in Body and elsewhere in the
> same clause).  That's both syntactically simpler and a smaller change
> to the language (though I expect it would be harder to implement,
> since you have to analyze the code to determine where to insert the
> commit).

The dealbreaker on that one is that *human readers* of the code would
*also* have to analyze the code to determine the place of the commit.
The point of the proposals is to use explicit syntax to mark the scope.

Zoltan.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------