[m-dev.] proof-of-concept code for choosing a grade

[Zoltan Somogyi]

On Thu, 11 Feb 2016 14:50:56 +1100, Paul Bone <paul at bone.id.au> wrote: 
> Sorry for the late comment on this.  I'm making an effort to catch up on
> Mercury things.

It may be more efficient to look at earlier replies to old proposals,
before you reply yourself :-(

> On Sat, Dec 05, 2015 at 01:39:41PM +1100, Zoltan Somogyi wrote:
> > 
> > I am mostly seeking feedback on the overall design approach.
> > 
> > - The decision to do it in C.
> 
> I think C is best in this case.  Before you can build a Mercury program you
> must configure and build the runtime and library.  The only way around this
> I think is to configure the libgrades after building the runtime and library
> in the pregen grade.  This would be possible but will probably confuse users
> too much, so I think a C program is best.

Actually, Julien convinced me that doing it in Mercury is OK, and
I rewrote the solver in Mercury, and committed it, two months ago.
It is now in the grade_lib directory.
 
> > - The representation of constraints. A conceptual constraint
> >   such as "debugging requires low level code" is expressed
> >   as two low-level constraints in cg.c: DBG=debug is allowed
> >   only if CL=lo, and CL=hi is allowed only if DBG=none.
> >   Each of the low level constraints expresses a requirement
> >   on a given solver variable s1 having a given value s1a:
> >   it requires that some other solver variable s2 have value
> >   s2a or s2b or ... If s1=s1a imposes requirements on
> >   more than other solver variable, those requirements
> >   need to be implemented as more than one low-level
> >   constraint. These low level constraints act as one
> >   directional propagators: if s2 cannot have ANY of
> >   the values listed (s2a, s2b etc), then s1 cannot be s1a.
> 
> I think I would prefer to have one constraint be used in both directions,
> to make it easier to understand this program and to add new constraints.
> But this decision makes implementation easier in other ways.  It depends
> where we'd prefer the complexity.  My feelings about this aren't very strong.

The Mercury version uses each constraint in both directions.

> > - The solving process consists of alternating propagation
> >    and labeling steps, but we don't backtrack over labeling
> >    steps; we commit to them. This works in this small
> >    constraint set; I am not sure whether it will work on
> >    our full constraint set.
> 
> We can always add backtracking later.  I would prefer to have backtracking
> than a fragile ordering of variables and values.

In Mercury, we can add backtracking later. In C, not really.
 
> > - C is typeless, but I tried to use a naming scheme that
> >   makes putting e.g. an integer representing a solver var id
> >   into a slot that expects e.g. an integer representing a value
> >   stand out. I also added a sanity check.
> 
> We can use an enum for the variables but values must be integers without
> adding casting.  This at least prevents mixing of variables and values.

In the Mercury version, the names of both solver variables and their values
are strings, but with a wrapper that distinguishes variables from values.
That is in the hand-written constraints. I am thinking of converting both
to values of (separate) enum types as part of the requirements setup process,
for speed, if benchmarking indicates this to be useful.

Zoltan.