[Mono-list] some questions?

[Adam Treat]

--- Fergus Henderson <fjh@cs.mu.oz.au> wrote:
> 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
> can
> 
> 	(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.]
> 

Well I can't say that I understand all that you are saying but I do
understand that "the magic" is there somewhere and that the common
language runtime is much more complicated than I had thought.

I was under the impression that a language could be dropped into .NET
without significant modification.  I see that is not the case.

> > 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?
> 
> No.
> 
> 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.

The lot with the caveat that some functionality will be handled with
interfaces to pre-existing functionality such as any calls to Microsoft
Outlook will be replaced with call to Evolution or some other mail
client right?  So we might be functionally equivalent or compatible
with Microsofts .NET _but_ not a mindless duplicate?  Is this right I
hope?  If this _is_ right I think it would be a good idea to address
this in the FAQ in a straightforward manner.  It might help to quiet
some fears.

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


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/