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

[Julien Fischer]

Hi Zoltan,

On Sat, 5 Dec 2015, Zoltan Somogyi wrote:

> Around oct 22-26 we discussed my proposal for a new approach
> to specifying grades. We agreed that it would need to be accessible
> not just in the Mercury compiler, but also in shell scripts.

I certainly posed the question of whether it should be accessible from
the shell scripts in the thread from October.  The only response I see
is from Mark who said he wouldn't consider it compulsory.  Neither would
I for that matter.

> While writing a constraint solver as a shell script is a VERY unappealing
> prospect, writing it in standard C allows it to be called from shell
> scripts, even before we have configured Mercury.

See below for the reason I don't want this implemented in C.  In the
October thread we discussed having 'compute_grade' as a Mercury library.
That would cover every use case, except use by the configure script (in
the absence of an existing Mercury implementation to bootstrap from).
I'm fine with that, the installation profiles I proposed around the same
time, should deal with most of the problems encountered in that use
case.

> So the attached
> code is in C. While this code is now a standalone program, my intention
> is that it should eventually divided into two or more separate .c files.
> One .c file would contain the actual constraint solver, but would do
> no I/O. Other .c files would act as wrappers: they would get the
> list of desired features and the results of autoconfiguration tests
> (such as whether we can use GCC registers), either from a file or
> from the command line, give this info to the solver, and output the
> results. There may be more than one of these, because you may
> want more than one input format and/or output format. And
> of course we could wrap the solver with Mercury code as well;
> such a wrapper should be able to replace (most of) the current
> compiler/compute_grade.m.
>
> This code is VERY preliminary. It implements only four solver
> variables instead of the couple of dozen we discussed, and
> only a few constraints. It takes input and generate output
> in a very simple form, as a set of solver var name = value
> pairs, which is NOT intended to be final. It is designed
> to be as simple as possible, not to run as fast as possible,
> but given the small problem size, I don't expect runtime
> to be a problem anyway.
>
> I am mostly seeking feedback on the overall design approach.
>
> - The decision to do it in C.

At a minimum this will significantly complicate building the compiler
using the non-C backends.  For the record, this currently works with the
Java backend and is fairly close to working with the C# backend.  While
I don't expect compilers built using the non-C backends to replace those
built6 using one of the C backends for day-to-day use, the ability to
build and install the system using non-C backends is an important test
of those backends and one that I would like to preserve.

As an aside, we should consider packaging up the Java version of the
compiler and distributing that (in addition to the other ways we
distribute Mercury).  For users who simply want to try Mercury out it's
a good deal simpler than compiling from the pre-generated .c files.

Julien.