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

[Paul Bone]

Sorry for the late comment on this.  I'm making an effort to catch up on
Mercury things.

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.

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

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

The implementation itself looks good.

Cheers.


-- 
Paul Bone