[m-dev.] Resources example

[Ralph Becket]

Peter Schachte, Thursday, 28 April 2005:
> 
> I think the interesting thing about the 'any' inst is that it makes no
> commitment as to the number of distinct possible ground terms that a
> particular term may represent.  But it probably is true that it would
> be sufficient to have resources and the ability to specify
> initialization and equality predicates in a type declaration to
> provide solvers.  I don't think you really need separate solver and
> representation types, just opaque types.

We want to leave the constraint store implicit in the solver interface.
I agree that resources would make the distinct types of solver types
irrelevant, modulo my comments below.

> > :- pred contains_duplicate(list(T)::in) is semidet.
> > 
> > contains_duplicate([X | Xs]) :- member(X, Xs).
> > contains_duplicate([_ | Xs]) :- contains_duplicate(Xs).
> > 
> > In this case my call to `contains_duplicate' silently updates the
> > `cstore' resource because unification for type `t' will update `cstore'.
> 
> True, just as a goal X = [] silently updates the heap.

Not in any observable way.

> > Under these circumstances the compiler can't do things like optimize
> > away duplicate calls to `contains_duplicate' *anywhere* that it can't
> > prove that the unification predicate for whatever T doesn't use some
> > resource.
> 
> Nope, because you've promised that unification (and all other
> constraint predicates) only modify the constraint store in a
> commutative and idempotent way.  If you haven't made that promise,
> then you have to precede your calls to those predicates with ! to
> specify that they may use and/or modify a resource in a possibly
> non-commutative, non-idempotent way.  Goals with the ! at the front
> cannot have those optimizations made, any more than goals that use
> state variables or goals in DCGs can.

I that case I can't allow my definition of unification to use resources,
so I need solver types again!

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