[m-dev.] Re: [HAL-dev] Adding Herbrand types to Mercury
Fergus Henderson
fjh at cs.mu.OZ.AU
Tue Jan 27 05:48:31 AEDT 2004
On 23-Jan-2004, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> (1) Solver types in Mercury
>
> Solver types are provided to support the implementation of constrained
> types such as constrained integers, partial orders and so forth.
> Implementation of solver types inevitably involves some impure coding
> behind the scenes to implement constraint stores and the like.
I don't agree that solver implemenations must inevitably involve impure coding.
But this is not important for your proposal.
> The syntax for solver type definitions will be as follows:
>
> :- solver type <typename>
> where initialisation is <initpred>, unification is <unifypred>.
>
> Calls to <initpred> are inserted during mode analysis to convert
> variables free >> any where necessary.
>
> Calls to <unifypred> are used to unify variables of the solver type (the
> only mode is <unifypred>(in(any), in(any)) is semidet.)
>
> Any view of values of the solver type must be provided by predicates in
> the solver type's defining module.
Sounds fine.
> TODO:
> - Support the new syntax.
> - Record the <initpred> and <unifypred> info somewhere in the HLDS.
> - Get mode analysis to schedule calls to <initpred> and <unifypred>.
> - I think that's it.
At some point the compiler needs to check that <initpred> and <unifypred> have the
right type, mode, and determinism.
> (2) Herbrand types in Mercury
>
> Herbrand types are a special kind of solver type supporting Prolog
> style unification.
>
> The syntax for Herbrand type definitions will be as follows:
>
> :- herbrand type <typename> ---> <du constructors>.
I think it would be nice if we could come up with a less jargonish term
than "Herbrand".
> Scheduling of the Herbrand unification X = f(Y, ...) (for some data
> constructor f) works as follows:
>
> inst(X) | inst(Y, ...) | scheduled goals
> --------+--------------+----------------
> free | some or all | init_Herbrand(V), ..., [for each free V in Y, ...]
> | free | construct X = f(Y, ...)
> --------+--------------+----------------
> any | some or all | init_Herbrand(V), ..., [for each free V in Y, ...]
> | free | construct Z = f(Y, ...) [for some new variable Z ]
> | | unify(X, Z)
This will lead to poor performance. In the case of X = f(Y, ...) where
X has static inst "any", but is bound at run-time, we should not need
to allocate any heap space.
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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