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

[Zoltan Somogyi]

On 27-Feb-2006, Fergus Henderson <fjh-mailbox-58 at galois.com> wrote:
> > 	one_member(Set, Item) :-
> > 		given Set = set_as_234_tree(Tree)
> > 		promise_same_solutions [Item] tree234.member(Tree, Item).
> 
> That looks good to me.

That's fine, but which approach looks *best* to you?

> > In schema 1, given would be an binary prefix operator whose second operand
> > has to be a promise_same_solutions goal, and whose first operand could be
> > either a unification or a conjunction of unifications.
> 
> The first operand should not be restricted to that form, IMHO.
> We should allow any goal.

Your argument convinces me we should allow calls. However, it doesn't argue
for allowing nonatomic goals (e.g. disjunctions).

Basically, the marker is for telling determinism analysis to ignore the cc-ness
of an atomic goal. Ignoring the cc-ness of an arbitrary compound goal is not
really well defined.

> > Any preferences on alternate keywords to use? I think promise_same_solutions
> > should stay as close as possible to promise_equivalent_solutions, which it
> > is a variant of. However, I am much less sure about "deconstruct". Since the
> > goals it marks form the domain of the promise_same_solutions scope, some
> > variation on promise_same_solutions_domain would be nice, but only if it is
> > much shorter. Ralph and Julien and I kicked around "promise_domain" and
> > "domain", but finally came down with a weak preference for "deconstruct".
> > Any concurring or dissenting opinions?
> 
> I strongly disagree with the keyword "deconstruct", since it often
> wouldn't make any sense putting that in front of a cc_nondet predicate
> call (std_util.deconstruct being the obvious exception :).

OK, that convinces me we should use a name that fits calls as well as
unifications. As I said, I wasn't very sure of "deconstruct" in the first
place, but I need concrete proposals of what to replace it with.
I have two, "domain" and "promise_domain", above. Any others?

> > promising anything about the purity of those clauses.  How about
> > ":- pragma promise_equivalent_clauses"?
> 
> That sounds good.

Good.

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