[m-dev.] New release?

[Zoltan Somogyi]

On Thu, 22 Oct 2015 16:01:55 +1100, Paul Bone <paul at bone.id.au> wrote:
> > > 
> > >     take the set of such choices expressed on the command line
> > >     if those choices are inconsistent, then
> > >         report an error for each source of inconsistency
> > >     else
> > >  5      while there are unbound variables
> > >             for each so-far unbound variable (any order):
> > >                 compute the set of values of this solver variable that are
> > >                     consistent with the values of the already-bound variables
> > >                 if this set contains just one value
> > >                     bind the variable to this value
> > >                     break out of both loops (back to line 5)
> > >             choose a variable (using "chosen order" as in Zoltan's line 5
> > >             bind the variable to the value in the set that
> > >                the user is most likely to implicitly want
> > >             (in the table below, the default is the most preferred value)
> > > 
> > > This ensures that if the user specifies TAR=java, then CL=high will always
> > > be set (via propagation) before a choice is made on a variable such as REG.
> > > (REG=n will be propagated soon after.)
> > 
> > The two algorithms are equivalent. If a solver variable is set by the user
> > (e.g. TAR=java), then no assignment can be consistent unless it includes
> > all the settings implied by that (in this case, CL=high). Whether you record
> > CL=high immediately or when the loop gets to looking at the possible values
> > of CL does not matter.
> 
> What if the loop records REG=y before it gets to CL?  Or will the "choosen
> order" always handle those situations?

In this respect, the order does not matter. What matters is this part
of my original algorithm:

      compute the set of values of this solver variable that are
      consistent with the values of the already-bound variables

The consistency check here does the job of the propagation steps you want,
and may (or may not) be implemented via propagation.

If some option set by the user requires CL=high, then y is not a possible
value for REG (since REG=y requires CL=low), even if you consider REG before CL.

> > You are taking this too literally. This is a design description, not code.
> > The reason why I kept the names short was to fit the constraints involving
> > them into 80 columns. The actual names of the mutables will be more verbose,
> > and in any case, no user will ever see them. They will see only the names
> > of the options, and I was explicit about the fact that I am not yet proposing
> > any names for THEM.
> 
> sorry.

No harm done.

> > > even choose the order dynamically or add backtracking.
> > 
> > I don't think that will be needed. I certainly hope it won't, because
> > implementing it in sh would be a bitch :-(
> 
> Yeah, I was worried the first time I read "solver variable".

That is one reason why this hasn't been done before.

The fact that Mercury precedes HAL is another :-)
 
Zoltan.