[m-dev.] Change grade handling

[Fergus Henderson]

On 23-Jul-1998, Thomas Charles CONWAY <conway at cs.mu.OZ.AU> wrote:
> 
> This change makes the parsing of GRADE/--grade strings more flexible.
> The GADE string can now have its components given in any order. The

s/GADE/GRADE/

> NEWS:	mention the changes.

Should be

	NEWS:
		Mention the changes.

> scripts/ml.in:
> 	Include .par in the grade string. (bugfix)

Perhaps that one should be committed separately.

> runtime/getopt.h:
> 	fix a prototype so that it *is* a prototype to shut up gcc.

This one should definitely be committed separately.

Also, this change might cause portability problems, so I'm
not sure that it is the right fix.

> +* The components of the GRADE mmake variable/the argument to the --grade
> +  option may now be given in any order. The compiler also has a new option
> +  `--output-grade-string' which prints the cannonical grade string for
> +  the set of options with which the compiler was invoked.
>
>  NEWS for Mercury release 0.7.3
>  ------------------------------

s/cannonical/canonical/

(`cannonical' means `like a cannon' ;-)

Also I suggest that be reworded slightly:

* The components of the argument to the `--grade' option and of the `GRADE'
  Mmake variable may now be given in any order. The compiler also has a
  new option `--output-grade-string' which prints the canonical grade
  string for the set of options with which the compiler was invoked.

Also, I think you added it in the wrong section -- it should go in
the "NEWS since release 0.7.3" section.

> +	% IMPORTANT: any changes here may require similar changes to
> +	%	runtime/mercury_grade.h
> +	%	scripts/parse_grade_options.sh-subr
> +	%
> +	% The grade_component type should have 1 constructor for each

I suggest s/1/one/

> +:- type grade_component
> +	--->	gcc
> +	;	gc
> +	;	prof
> +	;	trail
> +	;	args
> +	;	trace
> +	;	par
> +	;	pic
> +	.

Some comments here would help.

It might be better to rename `gcc' as `gcc_extensions'.

> +:- pred compute_grade_components(option_table,
> +		list(pair(grade_component, string))).
> +:- mode compute_grade_components(in, out) is det.
> +
> +compute_grade_components(Options, GradeComponents) :-
> +	solutions(lambda([CompData::out] is nondet, (
> +		grade_component_table(Name, Comp, CompOpts),
> +		\+ (
> +			list__member(Opt - Value, CompOpts),
> +			\+ map__search(Options, Opt, Value)
> +		),
> +		CompData = Comp - Name
> +	)), GradeComponents).

Some comments here would help.

> +	% GC components
> +grade_component_table("nogc", gc, [gc - string("none")]).
> +grade_component_table("gc", gc, [gc - string("conservative")]).
> +grade_component_table("agc", gc, [gc - string("accurate")]).
> +grade_component_table("par", par, [parallel - bool(yes)]).

"par" is not a GC component.

Why "nogc"?

options.m:
> +	io__write_string("\t\t--output-grade-string\n"),
> +	io__write_string("\t\tCompute the grade of the library to link with based on\n"),
> +	io__write_string("\t\tthe command line options.\n").

"..., and print it to the standard output."?

You need to modify doc/user_guide.texi.
As well as documenting this new option, you also need to modify
the "compilation models" section to reflect your changes.

> Index: scripts/ml.in
> +			none)
> +				asm_labels=false
> +				non_local_gotos=false
> +				global_regs=false
>  				;;

Is that still right?  
Now that you've eliminated the distinction between "base grades" and
"grade modifiers", why does `none' have a special effect on the use of
gcc extensions?


Once you've addressed these issues I'd like to see a relative diff.

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.