[m-dev.] hl (not hlc) grades

[Julien Fischer]

Hi Zoltan,

On Sun, 5 Apr 2020, Zoltan Somogyi wrote:

> Do we support the hl.gc grade (which uses high level data
> as well as high level code), or don't we? I seem to recall
> that we discussed removing support for the hl grade component,
> as we did with hlc_nest and hl_nest, but I don't recall the
> result, and I can't find the relevant discussion in mrev or mdev.

We certainly removed (some of) the user facing documentation for it.
(I just noticed a couple of references leftover in the user guide.)

I don't recall ever reaching a decision as to whether the hl.* grades
should be dropped.  In the past there has been some small value in their
presence; having a C grade that used --high-level-data was useful for
developing other backends that use that option (e.g. Java and C#).

If the last lot of benchmarking results I did between hlc.gc and hl.gc
(which was a *very* long time ago) hold, then there's no compelling
reason to use hl.gc over hlc.gc; the latter is always faster.

> The reason I ask is two-fold. First, a change I am working on
> would be simpler if it did not have to handle high level data
> grades targeting C,

I have no objections to removing the hl.* grades; clearly no-one is
using them and doing so would simplify some parts of the system.

> and second, when I tried a bootstrap in hl.gc, it failed almost
> immediately, when compiling the runtime, yielding the attached error
> from the C compiler, which for me is gcc 7.4.0. I don't know whether
> the error reflects bit rot in the Mercury system, or the effect of
> changes in gcc.

FWIW, it's almost certainly both, specficially GCC's error detection
capabilities have improved.

Julien.