[m-dev.] proposal: drop automatic initialisation of solver types

Mark Brown mark at csse.unimelb.edu.au
Fri Oct 26 18:40:18 AEST 2007


On 26-Oct-2007, Mark Brown <mark at csse.unimelb.edu.au> wrote:
> On 26-Oct-2007, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
> >
> > There has been an on-and-off discussion about removing support for 
> > automatic
> > initialisation for solver types.
> >
> > Automatic initialisation is problematic because:
> >
> > * it prevents solver types from being properly polymorphic, e.g.
> >   you cannot have the type foo(bar) where:
> >
> > 	:- solver type foo(T).
> > 	:- solver type bar.
> >
> > * the introduction of calls to the initialisation predicates complicates
> >   mode analysis.  Also, the compiler doesn't do a very good job of
> >   introducing them anyway: the introduction of the calls can change det
> >   code into semidet code etc.
> >
> > * we don't use automatic intialisation in practice anyway.  The solver
> >   types in G12 all require (or we recommend) using explicit
> >   initialisation predicates.
> >
> > * mode error messages are often poor or misleading because of
> >   interactions between automatic initialisation and impure code.
> 
> * Sometimes you don't want to provide =/2, but provide some other mechanism
>   for constraining variables to be equal.  In this case, it would be very
>   useful for the compiler to detect implicit attempts to use =/2, and report
>   them as a mode error.

I meant initialisation not equality -- sometimes there is no sensible
default (for example when the variables always have bounds, but there is
no maximum bound).  But I was going to point out that this problem is
similar for equality, so it might also be nice if the default equality for
solver types was to throw an exception.  Where possible, the compiler
could report use of the default as a mode error.

As the reference manual says, solver types which use the default equality
are not very useful.

> 
> >
> > In light of this, I propose that we drop support for automatic
> > initialisation.
> >
> > Objections?
> 
> Not at all.
> 
> Cheers,
> Mark.
> 
> --------------------------------------------------------------------------
> mercury-developers mailing list
> Post messages to:       mercury-developers at csse.unimelb.edu.au
> Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
> Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
> --------------------------------------------------------------------------
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list