[mercury-users] Stable .net backend?

[Fergus Henderson]

On 27-Feb-2003, Petter Egesund <petter.egesund at kunnskapsforlaget.no> wrote:
> Any clue about when the .net-backend will be stable enough for use.

We have made huge progress on the .NET CLR back-end in recent months.
The .NET CLR back-end in the current "unstable" release-of-the-day
distribution of Mercury (and the next "stable" release-of-the-day,
whenever that is) should be reliable enough to use now, provided that
you build with debugging enabled.  I was recently able to bootstrap the
Mercury compiler using this back-end, and it also passes more than 90%
of the tests in the Mercury test suite.

Note that the current mapping from Mercury to the .NET CLR is still
subject to change in the future.  So you should avoid writing code that
relies on a particular mapping, or at least try to write your applications
in such a way as to minimize any such dependencies.

The current known bugs are as follows:

	1. bootstrap:
		BUG: if the compiler is bootstrapped in grade `il' without
		debugging enabled, it dies with System.InvalidProgramException.
		Exact cause unknown.

	2. tests/hard_coded/null_char:
		BUG: strings containing special characters are not properly \
		escaped in the generated IL code, resulting in an error
		from ilasm.

	3. tests/hard_coded/exceptions/test_try_all:
		BUG: MissingMethodException for Void mercury.exception__cpp_
		code.mercury_code.builtin_catch_3_m4(System.Object[],
		System.Object[], System.Object[], Int32, UIntPtr).

	4. tests/general/string_to_float:
		MINOR BUG: -0.0 output as 0.0

	5. tests/hard_coded/sub-modules/parent2:
		MINOR BUG: the .NET CLR back-end requires main/2 be defined in
		the program's top-level module.

The remaining test case failures are due to either problems in the test
suite, or to use of features which are not yet implemented for the .NET
CLR back-end.  From README.DotNet:

 | Q. What features are not yet implemented?
 |  
 | A. The following standard library modules are completely unimplemented:
 |  
 |         benchmarking
 |         store
 |         time
 |  
 |    The standard library modules that provide RTTI are only partly implemented
 |    (basically just enough to make io.print work):
 |  
 |         construct
 |         deconstruct
 |  
 |    In addition, the following individual procedures from other modules
 |    are still not yet implemented:
 |  
 |         io.binary_stream_offset/4
 |         io.seek_binary_2/5
 |         type_desc.make_type/2
 |         type_desc.type_ctor/1

The other issue of interest is performance.  However, the license
for the Microsoft .NET Framework version 1.0 forbids me from releasing
benchmark results.  Microsoft has informed me that this will also be the
case for version 1.1 too.  Because of these appalling license conditions,
I can't give you performance numbers, and so I advise you to assume that
the performance is abysmally bad.

> We have a large project which starts after summer...

Oh, so you're starting on Friday then?
Good thing we got it ready just in time! ;-)

(The seasons, like everything else, are ..umop episdn,, here in Australia ;-)

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