[m-dev.] Resources example

[Ian MacLarty]

On 26 Apr 2005, at 13:57, Peter Schachte wrote:

> On Fri, Apr 22, 2005 at 06:25:24PM +1000, Ralph Becket wrote:
>> Peter Schachte, Friday, 22 April 2005:
>>>
>>> eq(A, B) :-
>>> 	promise_pure (impure X = 'representation of any po_vertex/0'(A),
>>> 		      impure Y = 'representation of any po_vertex/0'(B)),
>>> 	( if   path(X, Y, [], nonstrict)
>>> 	  then path(Y, X, [], nonstrict)
>>> 	  else not path(X, Y, [], strict),
>>> 	       svset.insert(le(Y,X), !po_store),
>>> 	       svset.insert(le(X,Y), !po_store)
>>>         ).
>>
>> Talking to Julien, we observe that this promise_pure goal, like others
>> in this example, is poorly scoped.  It is only the clause as a whole
>> that can be considered to have a pure interface.  The 'representation 
>> of
>> ...' functions are impure because a non-ground solver value may have a
>> ground representation, which can only make sense in the context of the
>> constraint store.  But that's implicit, hence the impurity annotation!
>>
>> A good fix would be to make 'representation of ...' use the !po_store
>> resource, in which case they would be pure.
>
> Yes, you're right.  Are these representation functions automatically
> generated?  If so, I guess there would have to be a way to add
> resources to them.
>
> I prefer my little extension to the solver type declaration allowing a
> list of predicates whose solver type variables are to be automagically
> converted so these predicates see those arguments as the
> representation type.  In this case the purity promise is made about
> whole predicates, so it is sound.
>

It sounds like a good idea to me to have two versions of predicates 
that put constraints on solver_type variables - one version that the 
user sees which has solver_type arguments and one version that the 
implementor of the constraint solver sees where the solver_type 
arguments have their representation types.

I propose extending this concept so that in addition to having 
representation argument types, the implementor version also has two 
extra arguments on the end -- representing the state of the solver 
before and after the constraint is added.  This would present a pure 
interface to both the implementor and the user without the need for the 
seperate concept of resources.  When declaring the solve_type you'd 
need to also declare the type of the constraint solver state, but I 
think that's probably a good thing.  The compiler could then put in all 
the impure code to convert the solver type arguments to their 
representations and retrieve the solver state from a global variable.

Ian.

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