[m-dev.] .NET & C interface

[Fergus Henderson]

Quite a few of the .NET test cases are failing because they use
C foreign_proc clauses, and the .NET back-end doesn't support the
C interface.

This is not the highest priority thing to fix, but nevertheless I've been
wondering about it.  One way to fix it would be by adding support for
the C interface to the .NET back-end.  There are at least two complete
C compilers which support compiling for the .NET CLR: MSVC's C mode,
and lcc 4.2.  The command-line version of MSVC is shipped with the (free)
.NET SDK.  Portable.NET also has a C compiler in the works.

However, there is one significant problem with this approach: it is likely
that a lot of the existing Mercury code which uses the C interface
makes assumptions about data representations which don't hold for the
.NET back-end.

Any suggestions about how we should deal with this?
Is it best to just go ahead and implement the C interface,
and then fix any non-portable C code?
Hmm.  Fixing such code may be difficult; in most cases where the code
depends on data representations, what you want is for the C foreign_proc
to only be used if the target uses those representations, and to fall
back to Mercury code if it doesn't.
Maybe we should add some syntax to indicate this?
Any suggestions on what form that syntax should take?

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