[Mono-list] some questions?

Fergus Henderson fjh@cs.mu.oz.au
Tue, 31 Jul 2001 06:36:41 +1000

On 30-Jul-2001, Adam Treat <manybooby@yahoo.com> wrote:
> 1. Suppose I were to write a compiler for java that
> generates CIL bytecodes. Would I be able to use the
> Mono libraries?

That depends.  Your compiler needs to not only *generate* CIL,
it also needs to be able to consume meta-data from PE files.
This takes more work than just writing a compiler that
produces CIL.

> The libraries are written in csharp
> which would seem to preclude there use in java... but
> isn't that the whole idea behind a common language
> runtime? What magic is this?

There are different levels of interoperability.
The ECMA spec defines different categories of
CLS (Common Language Specification) conformance.
There are also some useful categories that don't
correspond to any of the levels defined in the ECMA spec.
In increasing degree of difficulty, your language implementation

	(a) just generate IL

	(b) be a CLS "consumer", which means that it can read in
	  meta-data describing component interfaces,
	  and that it provides a way to declare variables of
	  CLS-complaint types and to call CLS-complaint methods.

	(c) be a CLS "extender", which means that it can in addition
	  derive from CLS-compliant classes
	  and implement CLS-compliant interfaces

	(d) be able to produce components with *any* CLS-compliant
	component interface.

Supporting some of these may require extending your language.  However,
you can get quite a lot of interoperability by just putting appropriate
functionality in your compiler, without extending your language.

For some things, e.g. ASP.NET, your language implementation also needs to be
able to

	(e) consume CodeDom trees.  CodeDom trees are an abstract
	representation of programs in a form similar to a C# parse
	tree, with embedded code snippets (unparsed strings).
	Given a CodeDom tree, with the snippets in your language,
	your language implementation needs to generate a (i) .NET
	assembly and possibly also (ii) a source file in your language.

	(f) produce CodeDom trees.  For some applications,
	your language implementation also needs to be able to
	round-trip from CodeDom -> your language -> CodeDom.

and for some things it needs to

	(g) generate *verifiable* IL

So when you hear all the hype about how language XYZ is a
".NET language", make sure you ask which of these different
things are supported.

[For the record, Mercury currently supports (a).  We're working on
(b) and (g), and on parts of (c) and (e).  We're never going to do (f), I very
strongly doubt we'll ever do (d), and for (c) we might only ever support
implementing interfaces, not deriving from classes.]

> 2. I take it that the Mono libraries are from the ECMA
> specs. Are these complete?

What do you mean by "complete"?

Is the C standard library "complete"?

Is Posix "complete"?

> I mean did Microsoft
> _really_ submit all of their .NET environment
> libraries to ECMA? Windows.Forms and ADO.NET and
> ASP.NET and everything?


The set they submitted is a reasonably useful set, though.  Think of it
as the .NET standard library, somewhat analagous to the C standard library.

But even for the things which are not submitted to ECMA,
the documentation is freely available from msdn.microsoft.com.

> 3. If the ECMA libraries are not complete... Is Mono
> attempting to produce an environment and libraries for
> Microsoft's version of .NET or just what is published
> under the ECMA?

The lot, I believe.

> 4. If Mono is trying to produce an environment
> compatible to Microsoft's version of .NET not just the
> ECMA specs then isn't that giving a lot of power to
> Microsoft? I mean not only could Microsoft choose to
> break compatibility, but they would have full control
> over the data schemes and the libraries as well...
> Doesn't anyone see this as a problem?
> 7. I have been monitoring the dotGNU list also and
> have been surprised to see quite a bit of malice
> towards Mono. Some have even suggested that Mono not
> be used as the runtime environment. This seems to be a
> tactical error. I was under the impression that dotGNU
> and Mono were to be complements of each other. Mono
> supplying the runtime environment and tools and dotGNU
> the authentication and web services. Can anyone
> clarify the relationship between dotGNU and Mono?

I'll leave those for Miguel ;-)

Fergus Henderson <fjh@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.