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

Zoltan Somogyi zoltan.somogyi at runbox.com
Thu Feb 11 17:54:59 AEDT 2016

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.


More information about the developers mailing list