[mercury-users] status of .NET support

Fergus Henderson fjh at cs.mu.OZ.AU
Wed Sep 4 06:13:37 AEST 2002


On 02-Sep-2002, Wendelin Reich <wreich at gmx.net> wrote:
> I fear that I am about to ask a pretty frequent question, but scanning
> through the archives of the Mercury mailing lists, reading
> README.DotNet, the documentation and related files, I still wonder what
> has happened to .NET support in Mercury. The page under
> http://www.cs.mu.oz.au/research/mercury/dotnet.html is obviously from
> last year, although the information it gives might still be up-to-date.
> But all this happened like 14-16 months ago, and .NET is already about
> to become a huge success, I think. Did Mercury's .NET-support make any
> significant progress since then?

As Peter Ross said, he has been working at this at Mission Critical.
We have also been working on it here at Melbourne.

Together, we have made significant progress.  However, most of this
has been in relation to issues such as using a higher-level data
representation (for better interoperability and better performance),
making use of null pointers and static objects to represent constants
(for better performance), solving the problems that arose with abstract
equivalence types (since .NET has no support for type synonyms), and such
like, which don't have *direct* user-visible consequences.  We have not
yet reached the point at which the .NET support is at "release" quality.

Tyson Dowd, who did quite a bit of the earlier work on the Mercury
compiler's .NET back-end, has gone into thesis-writing mode.  But I am
continuing to work on the .NET back-end (after a break of a few months
during which I was writing papers, attending conferences, and taking six
week's accumulated leave), and hope to make substantial progress in the
next few months.  As well as getting it to work with Microsoft's .NET
implementation, I also want to make it work with Mono and DotGNU's
Portable.NET.

One area in which we have made significant progress and that does have
direct user-visible consequences is the support for C#, IL, and Managed
C++ in our foreign language interface (when using the .NET back-end).

A related issue is that we now allowing procedures to be implemented
in both C and Mercury, with the C version used for the C and assembler
back-ends but the Mercury version used for the .NET and Java back-ends.
This has been used to deal with cases where procedures in the standard
library had been implemented in C for performance reasons, but could
easily be implemented in Mercury.

We're also continuing to negotiate with Microsoft about obtaining a VSIP
license so that we add support for Mercury to Visual Studio.  However,
the likelihood of a successful resolution there seems to be not very good.

The release-of-the-day release also includes Mmake-like build support
built into the compiler, rather than relying on GNU Make, which is
another step towards improving our Windows support by eliminating the
need to use Cygwin.  (However, we have not yet eliminated all dependencies
on Cygwin.)

> Will there be any information regarding how to *use*
> .NET-classes in Mercury?

Indeed.  In fact there is some such information already in the
"foreign language interface" chapter of the ROTD version of
the Mercury language reference manual, though it is definitely
very patchy still -- some important chunks are not yet documented,
or are documented as being "not yet supported" even though they
do in fact work.

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



More information about the users mailing list