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

[Zoltan Somogyi]

On Tue, 16 Sep 2014 14:57:18 +1000 (EST), Julien Fischer <jfischer at opturion.com> wrote:
> > About 360: the feature is not compatible with our current
> > implementation.
> 
> I'd worked that out based on the error message ;-)

I mean that it is incompatible with its basic idea, as in we cannot
lift the incompatibility without rewriting the minimal model tabling system
as a whole.

> It's likely to do both for different sets of users, I don't think
> there is any avoiding that.

Yes, I agree. That's why I asked my question.

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

> (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 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?

Zoltan.