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

[Tyson Dowd]

On 19-Apr-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> 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.

I agree, this is simply a matter of NYI (not yet implemented).
I will fix it.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------