[Mono-devel-list] Looking for Summer of Code Information

Jonathan Pryor jonpryor at vt.edu
Wed Jun 1 07:54:11 EDT 2005

On Tue, 2005-05-31 at 22:05 -0400, Justin Berka wrote:
> 1. Ruby.NET - Just how hard is it to write a compiler. Also, what kind 
> of existing tools would be used for this, and what would have to be 
> written from scratch?

In principal, it's not hard to write a compiler.  You just need a lexer,
a syntax analyzer, a semantic analyzer, and a code generator.  The lexer
can be built by existing tools (ANTLR, flex, bison, etc.), and ANTLR
provides ways to make the syntax/semantic analysis easier...

But it's still a lot of work.  You're easily looking at several
thousands of lines of code, which could easily take months.  Then
there's the code generator, which would likely be build atop
System.Reflection.Emit, and would thus require learning/understanding
Common Intermediate Language...

So, not easy, but not terribly difficult.  Just tedious, mostly.

The Dragon Book is the typical reference for learning about compilers:


> 2. MonoDoc - Could someone be a bit more specific about what needs to 
> be done here?

Use it, find things you don't like, and fix them. :-)

Or look at bugzilla.ximian.com.

Personally, I could go for a nicer editing mode that looked more like a
word processor instead of requiring XML input all the time.  Something
like a tabbed word processor/HTML editor -- one tab for XML source,
another for WYSIWIG editing...

(I can dream, right?)

> 3. CIL - both the "replacing CIL with native code" and API Problem 
> Finder. Where's a good starting point to read more about CIL and Cecil, 
> and could someone explain these in a bit more detail.

CIL is covered in the ECMA standard:


Which has an annotated book:


Other books also discuss CIL:


However, what do you mean by "replacing CIL wil native code"?  Mono
already does this, in two ways -- that's what a JIT does (generates
native code), and `mono --aot` generate ahead-of-time code (to avoid
runtime JITing).

Cecil is covered (vaguely) at 


The API Problem Finder is an reimplementation of FxCop; see: 


Many would like to see a mono equivalent to this...

 - Jon

More information about the Mono-devel-list mailing list