[m-rev.] diff: C# interface for .NET backend.

[Tyson Dowd]

On 02-May-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 01-May-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > The bulk of this change to delay the mangling of MLDS var names, so we
> > can still use the original user's var name when we output the outline
> > procedure (since the user's foreign code will refer to these var names,
> > it's important to keep them around).
> 
> Could you explain this point in more detail?
> 
> How does this differ between outline_foreign_code and inline_target_code?
> Shouldn't those two use the same approach?


The approach taken by inline_target_code is:
	Generate a procedure wrapper using mangled MLDS names (Str_2 and
	X_1 and so on).
	Generate local variables for Str and X.
	Generate local variables for any return values.
	Generate assignments of input variables to Str and X (if they
	are inputs).
	Insert user code.
	Generate assignments of output variables to Str_2 and X_1 (if
	they are outputs) and the return value.

But of course inline_target_code is only a small part of this, most of
it is generated by the code generator in ml_code_gen.

The approach taken by outline_foreign_code is:

	(in IL)
	Generate forwarding code (load all arguments to original
	procedure and call the C# function).

	(in C#)
	Generate a procedure wrapper using unmangled MLDS names (Str and X)
	Generate local variables for any return values (this is actually
	done by ml_code_gen)
	Insert user code.
	Return the return value.

So I need the unmangled variables because the C# code is going to use
and assign to them.

This seemed to be this least hacky way to pass the unmangled MLDS
variables around.

Everything else seemed a bit more fragile -- passing the unmangled variables
separately means you have to duplicate all the processing (removing
dummy variables, adding new variables, etc).  Unmangling the variables
at the last minute seemed error-prone if the mangling ever changed.

The only other option that seemed somewhat reasonable is to generate a
new function for the C# code, that is marked in some way as special
(implemented in foreign code).  This might be a nice way to go, but it
seemed to be a more difficult approach.

-- 
       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-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
--------------------------------------------------------------------------