[m-dev.] Grade handling

[Fergus Henderson]

On 20-Jul-1998, Thomas Charles CONWAY <conway at cs.mu.OZ.AU> wrote:
> 
> The mechanism for handling different grades of compilation seems to be
> rather unwieldy, and difficult to maintain.

Do you mean for unwieldy for users, or unwieldy for implementors?

Users shouldn't use `--grade' or `GRADE='; that's really there just
backwards compatibility only.  They should instead use `--gc conservative',
`--use-trail', etc., and `GRADEFLAGS='.

Regarding maintenance difficulty, I'd be happy with any concrete
suggestions for improvements.  But I don't see how your suggestions
below would help.

> I propose to change the way
> we deal with grades as follows:
> 
> 	- A grade should be a string made up of `.' separated components.
> 	- Each component specifies some compilation feature.
> 	- Features can be given in any order.
> 	- The empty string corresponds to the current grade "none".

Why not

	- A grade should correspond to a set of options
	- Each option specifies some compilation feature
	- Options can be given in any order
	- The empty set of options corresponds to the default grade

?

That is, the status quo ;-)

The implementation still needs some canonical name for each grade
so that it can use this name for the name of the directory in which
to find the libraries for that grade.  So at that point at least,
the order must be significant.

We could allow the order to be insignificant in the `--grade' option,
but users shouldn't really be using the `--grade' option anyway,
so there's no point.

> Two ways of handling the grade come to mind:
> 	- Use a table which maps a grade component to a list of options to
> 	  set.

That's very similar to what we currently do, except that currently this
is done with a piece of code, rather than a table.

This piece of code is in scripts/parse_grade_options.sh-subr
and also in compiler/handle_options.m, but I don't see any easy way
of avoiding that code duplication, since this mapping is used
both by Mercury code in the compiler and by Bourne shell code
in mgnuc.in and ml.in.

> 	- A separate "grade" type which is tuple of all the grade dimensions.

In the Mercury code, we just use the `option_table' type for this.
In the Bourne shell code, we just use a set of variables.
I don't see what advantage there would be in changing that.

Cheers,
	Fergus.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.