[m-dev.] IL and --high-level-data (was: read .opt files transitively)

Fergus Henderson fjh at cs.mu.OZ.AU
Thu Apr 19 14:56:28 AEST 2001


On 18-Apr-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> Here's (a first draft of) a change to read in the `.opt' files transitively.
> See my post to mercury-developers for detailed rationale.
> 
> With this change, `tools/bootcheck --grade il' gets as far as building all
> the `.opt' and `.trans_opt' files, but dies when compiling benchmarking.m;
> the problem there is an unrelated one, namely that the IL back-end doesn't
> support nested classes.

Tyson, could you please have a look at that problem?
It occurs with 0.10.1 and the current mercury-latest compiler too.
(To reproduce, do `cd library; mmc --grade il benchmarking.m'.)

The problem is that with `--grade il' (which implies --high-level-data),
ml_type_gen generates nested classes, but mlds_to_il doesn't handle them.
 mlds_to_il.m dies at line 670:

		% XXX this might not need to be implemented (nested classes)
		% since it will probably be flattened earlier.
	defn_to_class_decl(mlds__defn(_Name, _Context, _DeclFlags,
			mlds__class(_)), _ILClassDecl) :-
		error("nested data definition not expected here").

I think it is definitely right for ml_type_gen.m to generate nested classes.
The nesting is needed to avoid name clashes if the same constructor name is
used in different types.  For Java, nesting is the the right solution for
that.  I'm not quite sure what the ideal way of handling it is for the
.NET back-end, but in any case I think it should be the .NET back-ends
responsibility to deal with nested classes in whatever way is most appropriate
for that back-end.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list