[mercury-users] Stable .net backend?

[Wendelin Reich]

Hej Petter,

Probably I can relieve the Mercury developers a bit if I give your
question a reply from the perspective of an outsider. I have recently
toyed a bit with the .NET-backend and think that it is already "stable
enough for use". Of course, some things are more stable than others. If
I understand it correctly, IL-code generation has worked for more than a
year and hasn't changed much since. The last major backup to the
.NET-backend (end of October, wasn't it?) seems to have concerned mostly
the library and documentation. Some relevant parts of the library have
not been ported yet, although much of the basic stuff (including stuff
like most of the array-module, which is mostly written in C/C++) has
been ported.

So depending on your project, you might already be able to start. Just
be aware of the current and the perennial limitations. I would say that
the strength of the .NET-backend lies in making algorithms written in
mercury available to native .NET programs. Your .NET application is in
control of the big picture, while mercury supplies the logic of anything
that can be described as a function (I mean a transformation of some
input into some output). However, anything that involves maintenance of
state (that includes event-based programming, which is the common case
on Windows) as well as intensive usage of .NET-libraries might be
tedious to implement in mercury. For any .NET-class to access, you have
to write a C# or MC++-wrapper through Mercury's foreign code interface,
which is okay if you use it only occasionally.

What is definitely not yet stable is the mapping between .NET-types and
mercury-types. If you use mercury types such as lists and return them to
calling C#-code, you will discover that their presentation is extremely
complex and inefficient. To my knowledge, the only composite
mercury-type which is more-or-less easy to access is the array, because
it is mapped to CTS-arrays. However, Fergus Henderson told me that the
representation of other types is not yet stable - if you have to pass
complex arrays-of-composite-types (say, pairs) between mercury and C#,
future releases of the compiler might require you to tweak your
application.

In any case, I found that working with mercury-assemblies from within
Visual Studio.NET is actually quite easy. First, you use ILDASM to find
out whatever names and namespaces the compiler chose for your
predicates. Second, you use Microsoft's debugger to find out about the
exact runtime representation of objects returned by your
mercury-predicates. Like that, you find out easily that you have to
write rather bizarre code such as the following:

using mercury;
...
private string CallMercury()
{
	mercury.std_util.pair_2[] x = null;
	my_assembly.mercury_code.get_some_array_of_pairs3_1(ref x);

	string output = "";
	if (x.GetLength(0) > 0)
	{
		for (int i = 0; i < x.GetLength(0); i++)
		{
			output += x[i].F1 + "\t";
		}
		for (int i = 0; i < ((int [])x[0].F2).GetLength(0); i++)
		{
			output += "\r\n";
			for (int j = 0; j < x.GetLength(0); j++)
			{
				output += ((int
[])x[j].F2)[i].ToString() + "\t";
			}
		}
	}
	return output;
}

:-)

Best wishes, Wendelin

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------