[m-rev.] for post-commit review: fix mantis bug 361

[Julien Fischer]

On Tue, 16 Sep 2014, Zoltan Somogyi wrote:

>
> On Tue, 16 Sep 2014 14:57:18 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>
>> More generally, I think the are quite a few problems with grade
>> components.  Of the top of my head:
>>
>> (1) Too many experimental or not-useful grade components are currently
>> documented at the user-level, for example agc, hl, il, hgc, jump, fast.
>
> Do you want to post a list of the grade components,
> and whether you think they should be exposed to users?

Ok.  Here are the grade components that I think should be visible to users
and publicly documented:

Base grades: none, reg, asm_fast, hlc, java, csharp, erlang

Rationale: most of the other base grades exist only to test various compilation
model options that were never intended to be visible to users.  Of the others
that are documented in the --help message, 'jump', 'asm_jump' and 'fast' are
not tested anywhere near as much as the others and may even be broken; 'hl' is
slightly slower than 'hlc' and doesn't provide any other benefit; 'il' hasn't
been worked on in years.

Modifiers: gc, prof, memprof, profdeep, tr, trseg, spf, stseg, debug,
            decldebug, par, ssdebug, threadscope, pregen

* I have long intended to make 'tr' imply 'trseg' and get rid of the latter,
   so in the long term it will go.
* 'threadscope' seems to spend more time broken than working, but I think
   Paul still intends to do something with it.
* Users that build the source distribution will obviously encounter the
   'pregen' grade component but that should be its only use.
* There is certain class of user, those who write Mercury programs containing
   significant amounts of C foreign code, for whom the 'll_debug' grades are
   probably useful, so maybe that component should be included as well?

All other grade components should be removed from user facing documentation.
That includes, the reference manual and user's guide, the compiler's usage
message, configure scripts, INSTALL file.  Furthermore, the configure script
should be modified so that it doesn't automatically select one of the more
obscure base grades if some of the feature tests fail.

Provided everyone is happy with the above, it's probably easiest for me to make
this change.

>> (2) The compiler currently does not do a good job of reporting
>> incompatible grade components in many cases.  For example, I accidently
>> tried to compile a program in the grade hlc.gc.mm recently and while I
>> did get a runtime error from the program, the compiler probably
>> shouldn't have ever let met get that far.
>
> Agreed. This is one case where a bit of code triplication (doing these
> consistency tests in C in the runtime, in sh in a sh-subr for the mmc/ml/etc
> scripts, and in Mercury in the compiler), would be the least bad option.
>
>> (3) The grade component options, --debug, --trailing, --parallism, etc,
>> seem to be a great source of confusion for users.  They seem to expect
>> that, for example, --debug will prepare their program for debugging;
>> what it in fact does is add the .debug component to the current grade.
>> On systems where the default grade is hlc.gc, this results in
>> compilation errors when the user does 'mmc --debug foo.m'.
>>
>> I think we should consider renaming all the existing grade component
>> options and have options like --debug mean something like "choose the
>> best available grade that supports debugging".
>
> I agree about the confusion, and that we should do something to
> fix it. However, keeping the names of options but changing
> their meaning will only increase confusion in the short term.

I meant after a suitable period of transition; I certainly wasn't suggesting we
suddenly just change the meaning of the existing options!

> I suggest adding alternate names for --debug, --trailing etc, names
> that mention that these are grade components, names that
> all follow the same template. For a while, we can encourage people
> to use those instead of the old option names. We can also add
> new options that do what people expect from the old options,
> with their names following another, distinct naming scheme.
> After a period of adjustment, we can change the old option
> names to be synonyms of the 'choose-the-best' options,
> not the 'grade-component' options.
>
> Any objections, or opinions about what these naming schemes
> should be?

There are no objections from me (obviously!).
For the grade-component options, I suggest the following scheme:

    --add-grade-component-<feature>
    --remove-grade-component-<feature>

For example:

    --add-grade-component-debug
    --add-grade-component-decldebug
    --add-grade-component-parallelism
    etc

That said, other aspects of grade component selection, for example target
language and garbage collection strategy are fine as they are.

Cheers,
Julien.