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

Fergus Henderson fjh-mailbox-58 at galois.com
Mon Feb 27 23:52:56 AEDT 2006


On 27-Feb-2006, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> The HLDS has already been modified to represent these new goals,

It helps if the names used in the HLDS match the syntax and terminology
used in the reference manual, so in general I would advise waiting until
the design has settled a bit more before implementing it.

> Here are three possible schemes, and how one_member would look with each
> schema.
> 
> 	Schema 1
> 	given (
> 		Abstract1 = f(Concrete1),
> 		Abstract2 = f(Concrete2)
> 	) promise_same_solutions [Vars] (
> 		...
> 	)
> 
> 	one_member(Set, Item) :-
> 		given Set = set_as_234_tree(Tree)
> 		promise_same_solutions [Item] tree234.member(Tree, Item).

That looks good to me.

> 	Schema 2
> 	promise_same_solutions [Vars] (
> 		deconstruct Abstract1 = f(Concrete1),
> 		deconstruct Abstract2 = f(Concrete2),
> 		...
> 	)

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

In particular, calls to cc_nondet-moded predicates should be just as
valid as deconstruction unifications. 
For example, calls to "std_util.deconstruct", etc.

Otherwise we would prevent people from using procedural abstraction.

> Any preferences on what schema we should follow? My vote, Ralph's and Julien's
> is for schema 2. It is syntactically less complex than schema 1, and compared
> with schema 3 and 4, its advantage is that it uses the deconstruct operator
> in a similar way to how we already use the impure and semipure operators.
> 
> 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 :).

> On a distinct but related matter, we currently consider any predicate
> defined by mode-specific clauses to be impure unless promised to be pure
> with a ":- pragma promise_pure" declaration. The problem with this is that
> ":- pragma promise_pure" is also used to promise away actual impurity
> in the clauses themselves. I think we should provide a new pragma that
> promises merely that the mode-specific clauses are equivalent *without*
> promising anything about the purity of those clauses.  How about
> ":- pragma promise_equivalent_clauses"?

That sounds good.

-- 
Fergus J. Henderson                 |  "I have always known that the pursuit
Galois Connections, Inc.            |  of excellence is a lethal habit"
Phone: +1 503 626 6616              |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the developers mailing list