[m-dev.] Resources example

[Peter Schachte]

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.

> I'm going to put my hand up here and say that my main concern about
> resources is the huge scope for abuse.  But I also acknowledge that
> sometimes imperative style is the clearest way to express things and
> there is a good case for providing support for disciplined imperative
> style.

You can still only do things you could do by threading extra
arguments.  There's nothing non-backtrackable here, as there may be
when using impurity to modify global state.  We also don't need to
rely on the implementation details of a pragma for correctness, as the
original code does.

As for the wider argument that having resources creates a large scope
for abuse, I disagree.  Firstly, impurity creates a far larger
opportunity for abuse, and I don't get the impression that this has
proved to be a problem.  And secondly, I don't think anyone would
abuse the feature in the way I imagine you are worried about:  passing
too many inputs and outputs as resources.  Unless a value is being
threaded through much code, using resources to pass it around is more
verbose and less convenient than just passing ordinary arguments.

Resources are only really usable where some entity is threaded through
many predicates, such as an io__state through I/O code, or a variable
counter through a term parser that needs to allocate variable numbers.
Or for threading a solver state.  In such cases, a resource is a win
because it's given an enforced consistent name everywhere, and the
type is only specified once, making maintenance easier.  Also, by
making argument lists shorter, they make it easier for a human to
match up actual and formal parameters, or to change which resources
are threaded where.


-- 
Peter Schachte              If we do not succeed, then we run the risk of
schachte at cs.mu.OZ.AU        failure.
www.cs.mu.oz.au/~schachte/      -- Dan Quayle, March 1990 
Phone: +61 3 8344 1338      
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------