[m-rev.] for review: fix .NET commit handling

[Fergus Henderson]

On 11-Jul-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> Fix the handling of commits in .NET.
> 
> compiler/ml_code_gen.m:
> 	Initialize (new_object) the commit object just before we throw it.

ml_code_gen.m shouldn't have any target-specific stuff.
At worst there should be stuff which is dependent on target capabilities,
(e.g. "target_supports_computed_goto").

So I think the "newobj" call should be done in mlds_to_il.m, when expanding the
"do_commit" instruction.

(But see below.)

> Index: compiler/ml_elim_nested.m
...
>  	( Target = il ->
> +			% Generate a ctor for the class.
>  
> +			% XXX we can't generate an empty constructor,
> +			% because the IL backend interprets that as
> +			% :- external.
> +			% So we generate an empty block instead.
> +		Stmt = mlds__statement(block([], []), Context),
>  
> -		Stmt = mlds__statement(atomic(Rval), Context),
> -		Ctor = mlds__function(no, func_params([], []), yes(Stmt)),
> +		Ctor = mlds__function(no, func_params([], []),
> +				yes(Stmt)),
>  		CtorFlags = init_decl_flags(public, per_instance, non_virtual,
>  				overridable, modifiable, concrete),

There shouldn't be an XXX on that comment.
An XXX would indicate something that we ought to fix later,
but this comment is just explaining why it was done the
way it was, not pointing out a hack or suggesting something
that could be fixed later.

In fact, I'm not sure if the comment really helps at all.
What do you mean by an "empty" constructor?
What's the difference between an "empty constructor"
and a constructor whose body is an empty block?
I guess you mean that the third field of mlds__function
can't be "no".  But the meaning of "no" there is already
documented in mlds.m.  (This meaning is not specific to
the IL back-end, by the way.)
Still, better too much documentation that too little, I suppose.

More importantly, that shouldn't be done in ml_elim_nested.m.
ml_elim_nested.m shouldn't have target-dependent code.
At worst there should be stuff which is dependent on target capabilities
(e.g. "target_supports_computed_goto").

However, I suppose it's more important get it working first.
So I suggest you go ahead and commit that.
I'll fix the modularity problems.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------