[m-dev.] New release?

[Zoltan Somogyi]

On Thu, 22 Oct 2015 15:25:02 +1100, Paul Bone <paul at bone.id.au> wrote:
> It looks like lines 8-9 are intended to implement a propagation step.  In
> that case I would prefer to use a while loop (line 5), and propagate to
> _any_ variable with a singleton set of "consistent values".
> 
> For example:
> 
>     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.

> > solver variable TAR:
> >     TAR.c:  C
> >     TAR.cs: C#                      (requires CL.hlc)
> >     TAR.j:  Java                    (requires CL.hlc)
> >     TAR.e:  Erlang                  (requires CL.hlc)
> >     (default is TAR.c)
> 
> I think that "j" is the name of a language.  We may want to avoid confusion
> and call this "java".

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.

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

> If a user has not specified anything and a their platform supports REG but
> not GOTO, and REG=y is selected first, then that would propagate CL=llc.
> Unfortunately they'll end up with a grade like reg.gc when they could have
> had a faster grade like hlc.gc.  This can probably be fixed by always
> choosing CL before REG, GOTO or ASM.

Or by having the choice of CL (in the rare case when it isn't implied by other
options) be influenced by the availability of registers, labels etc on the platform.

> > solver variable GC:
> >     GC.no:   no gc
> >     GC.bdw:  boehm gc
> >     GC.bdwd: boehm gc debug
> >     GC.nat:  native gc              (requires CL.hlc and TAR.{java,erlang,XXX}
> >     GC.acc:  accurate gc            (requires CL.hlc and TAR.c)
> >     GC.rafe: becket history gc      (requires CL.hlc and XXX)
> >     (default is GC.bdw)
> 
> While GC=nat requires TAR=java, erlang or C#.  I think it's more natural to
> make this propagate the other way.  So TAR=java implies GC=nat.  (Both are
> logically true, just from a user's perspective.)

Again, you are reading this proposal as being more concrete than it was
intended to be. I am only describing constraints; I am NOT proposing
ANYTHING about how they should be solved. The XXXs and ???s show
I am not even sure about the exact set of constraints we need.

> > solver variable TSCOPE:
> >     TSCOPE.n: no threadscope
> >     TSCOPE.y: threadscope           (requires XXX)
> 
> You have this as SCOPE above.  TSCOPE is probably a better name.

Again, it this point in time it does not matter.
 
> I started work to rename this completely, after realising that support for
> Mercury in the threadscope viewer would frequently be broken.

Rename what in what?

Zoltan.