[m-dev.] Resources example

Ralph Becket rafe at cs.mu.OZ.AU
Tue Apr 26 14:40:42 AEST 2005

Peter Schachte, Tuesday, 26 April 2005:
> 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 occurs to me that, apart from initialisation, you don't need solver
types at all if you have resources.

The key thing about solver types is the `any' inst, which effectively
says that the denotation of a variable with inst `any' can only be
decided with respect to the current (implicit) constraint store state
for that variable's solver type.

With resources, we don't need inst `any'.  Instead we just make
unification etc. for a "solver type" use the resource corresponding to
the appropriate constraint store.

Now, let's say `t' is a type implementing Herbrand terms, `cstore' is
the resource carrying around the constraint store for `t' values, and Xs
is a `list(t)'.  Now I want to call `contains_duplicate(Xs)' where

:- 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'.
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.  This seems like a real show-stopper to me.

If my argument holds water, then resources become much less attractive
because they stymie any chance the compiler has of performing any real
analyses or optimizations.

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

More information about the developers mailing list