[m-dev.] Resources example

Peter Schachte schachte at cs.mu.OZ.AU
Wed Apr 27 16:43:47 AEST 2005


On Tue, Apr 26, 2005 at 02:27:30PM +1000, Ian MacLarty wrote:
> 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.

That would handle tells OK, but it won't handle asks.  However, I
think you could make a slightly more complex proposal work.

Here's a reconceptualization of solvers.  Almost all ordinary Mercury
predicates cannot be interpreted without using and/or modifying global
state:  ie, the heap.  Solver type predicates are the same, except
that they use and modify a different global state.  So let a solver
type declaration specify extra values (and their types and initial
values) to thread into and out of particular predicates.  Some
predicates, asks, will only have the value threaded in; this
guarantees that they can be reordered wrt one another, but not wrt
predicates that thread the value through.  There should be some
annotation (resources make you put a ! at the front of the goals) to
tell the reader that the tells can't be reordered wrt the asks.  There
also needs to be a way to specify that a predicate threads the solver
state through, but its behavior depends on the input solver state and
the output solver state differs from the input only in
equality-preserving ways.  Such predicates are actually asks, but may
cache intermediate results in the solver state.  All of these things
are supported by resources.

I do think it's a good idea to allow the solver declaration to list
several values to thread, because allowing only one forces many
predicates to unpack and repack structures.  This just makes the code
messy for no reason.  Avoiding unpacking and packing is one of the
main reasons the solver I mailed around is simpler than the original.
In that code, init is the only predicate that needs the counter, and
it doesn't need the solver state at all.

Effectively what this proposal does is to add resources to Mercury,
but only for solvers.  I still think the more general resources
facility would be nice to have for lots of things other than solvers.

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



More information about the developers mailing list