[Mono-list] Compromises, and the lack thereof

[Miguel de Icaza]

Rhys,

As I said before to you on e-mail there are a couple of groups here:
the compiler and related tools, the class libraries and the runtime
engine.  

We consider the runtime engine to be highly important to us
(specially, as our compiler is written in C#), but also because that
is where ultimately we envision our applications to be running on.  So
we need to make sure that the runtime has the kind of features that we
need.  That is why we are working on the mono runtime. 

The class libraries is an effort that should be shared by anyone: both
Open Source and proprietary implementations of the CLI should benefit
from an Open Source class library, and I am more than willing to make
any configuration and packaging changes to accomodate the needs of
other CLI runtimes (Portable.NET included of course).

We have a small disagreement on PInvoke, but it is so small and
insignificant, that even if we disagreed violently the worst that can
happen is that a small enough "private" class would have to be
different (say, 2k to 4k lines of code).

As to the compiler, ideally I want it to be a C# component that can be
reused by something like SharpDevelop directly.  

Ideally various language front-ends could generate a semantic tree,
and all these front-ends could share the code optimization and code
generation classes.

There are other people interested in working on the .NET effort which
are currently outside of my team's scope: For example, there are
people interested in doing a GCC front-end to C# which should be able
to benefit from the class libraries and our runtime to load dynamic
classes.  I would love to see an effort to have a GCC front-end that
takes CIL images on the input and generates native code on the output.
I would also love to see a GCC backend that would allow all the
currently supported GCC languages to emit CIL bytecode. 

I do not know how things are going to turn out to be and how people
will use these different tools and how they will interact with them.  

I always thought the Java compiler on Linux would be Guavac, but as it
turns out, the Java compiler on Red Hat is KJC (which is a Java
compiler written in Java).  

I feel more productive using C# than using C, and that is where my
desire to work on a C# compiler written in C# comes from.

Rhys, you had in the past weeks changed your mind from focusing on
having a C# compiler that targets the JVM to something else.  

When I asked you for what exactly you were going to work on which was
not `everything but the class libraries' towards trying to reach an
agreement.  At this point, after only two emails you told me that I
was wasting your time, and that we were at `war' or something along
those lines.  

The class libraries is a task that is very easy to parallelize:
different teams can work on different parts of the class libraries
without stepin on each other toes, and there is a large ammount of
work to be there.  Here is where the distributed nature of Open Source
works the best: people with expertise in a particular area can be very
efficient and can code with passion the parts they like the most.

The compiler and runtime are best bootstrapped by a small team.  Once
there is a skeleton and an initial architecture to build upon, you can
actually involve more contributors.  

I believe that the resources that Ximian is devoting to this project
will be better spent on making sure that the tasks that are hard to
parallelize and require a less distributed and more coordinated effort
will happen.  To us, Mono is critical to build our next generation of
applications at Ximian and we will only increase our resources in the
area as the technology matures.

Best wishes,
Miguel.