[m-dev.] Reconsidering initialisation of solver types

Ralph Becket rafe at csse.unimelb.edu.au
Thu Jul 27 16:16:41 AEST 2006


Peter Schachte, Thursday, 27 July 2006:
> On Thu, Jul 27, 2006 at 03:37:37PM +1000, Ralph Becket wrote:
> > Peter Stuckey, Thursday, 27 July 2006:
> > > It makes Mercury unusable as a constraint programming language!
> > 
> > Currently automatic initialisation seems to make Mercury a bit of a pain
> > as a constraint programming language :-)
> 
> Why would it be a pain if you don't use it?  The pain would be if you
> wanted automatic initialisation but Mercury didn't support it.

There are at least two sources of pain:

(1) you forget to initialise some variables and the Mercury compiler
does a bad job of deciding which ones to initialise for you, leading to
heinously confusing mode, determinism and purity error messages;

(2) you rely upon automatic initialisation, but the compiler has a
different idea of what the "obvious" initialisation set is, leading to
heinously confusing error messages.

> Manual initialisation makes Mercury programs look more imperative than
> they need to.  I'd like to see us move in the other direction, getting
> rid of as much impurity as possible.

Initialisation is pure.

For many solver types, initialisation is usually necessary anyway (e.g.,
it's uncommon to have unconstrained FD or set variables, and even most
LP variables are supposed to be non-negative).

Just looking at the Mercury CLP programs we've written, adding explicit
initialisation would add epsilon to the code length.  The payoff would
be a more robust Mercury compiler with more useful error messages.  At
the moment it's rather painful debugging Mercury CLP errors.

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