I love C# very much, and the new extensions that are being added to C# will improve the language in many areas:

• Iterators: they simplify authoring the IEnumerable/IEnumerator interfaces in a class. Very nice.
• Anonymous methods: reduce the glue required for small use cases. For large cases, you dont want to use them anyways, as they make your code look ugly (remember: if a function does not fit on the screen, its probably buggy).

Those will reduce the amount of coding required in some scenarios, but they do not address some of the most common problems that programmers face: strings and regular expressions.

.NET ships with a very powerful regex engine. The engine is so powerful, that it is possible to use it to implement very advanced regexp-based applications. Its as easy to use as the POSIX regex API is: slightly more verbose due to its OO heritage, but in general, very similar.

The problem is that there is no simple way of using this API from a language like C#: the developer is stuck with this low-level API. Perl and Python both bundle powerful regular expression engines that are bound in a fairly usable way in the language.

Its a shame that C# does not have any simple way, or a nice syntactic sugar to manipulate this common idiom.

Strings manipulation in C# falls on the same category: some work was done, but it was not really completed. Adding a few overloads to the class libraries would make C# a sweet language for string processing.

A two parameter indexer: string this [int start, int end] would clear a lot of the confussion with Substring arguments (a previous log entry has more details).

Although we could add this to Mono, the result would not be portable to .NET.

Finally, there is the Stream problem. Reading a file in .NET involves two steps: opening the stream, and then creating a streamreader to read from it. The code looks a bit like this:

	Stream st = File.OpenRead ("notes.txt");
	StreamReader re = new StreamReader (st);
        string line;
			
	while ((line = re.ReadLine ()) != null)
		Console.WriteLine (line);

Wouldn't it be nicer, if you could just do:

	string line;
	while ((line = File.OpenRead ("notes.txt")) != null){
		Console.WriteLine (line);
	}

The above could be easily implemented by having the FileStream implement IEnumerator as Guido does in Python.

A new version of Mono has hit the streets. This version is obviously the best Mono release ever. A roadmap to Mono 1.0 is also being prepared as we speak, for the joy of all the Mono users.

Duncan surprised me on Sunday with a C# Cairo binding. This was fast, and am really glad to see it happen so quickly.

Duncan and myself left the office early today to attend Don's keynote at the XML web services conference.

It was good to see Don, despite having taking a red eye the day before, he did an outstanding presentation on web services and showed some of the new features in C#.

Went to Provo today to do a small presentation about Mono in an open session to Novell engineers. It went pretty well, and I also got to talk with various developers about Novell's existing product line.

Of particular interest are iFolder and NetMail

I signed my lease for my new apartment, which will be just a few blocks away from my current place. Nat will be my neighbor.

A fresh new chapter begins.

More updates at Nat's site

Two fantastic movies this weekend. I just finished watching Was tun, wenn's brennt? which Laura recommended. Yesterday Alex, Nat and myself went to see L'Auberge Espagnole.

Maria Laura in Mexico:

Guido recently quoted a conversation we had about Parrot. I said to him that the Parrot VM design was based on ideology (Guido quoted me as saying religion ;-).

One of my favorite books is Computer Architecture: A quantitative approach.

The parrot design is based on ideology because some of the core design considerations are just that: `real machine use registers, hence register-based intermediate code is faster'. An ideology-based design is one where the design decisions are driven by punch lines and not by a careful and quantitative study of the problem at hand.

Mono implements the .NET virtual execution system; This execution system uses a stack-based instruction set to transport code. Mono never actually sees the stack operations, because we treat the stack-based operations by their name: a serialization format for a tree representation of the original code.

So for example, if you have an operation like:

		a = b + c;

The code can be thought of as:

A possible serialization of this tree is easily expressed by a lisp-like expression:

	(assign a (add b c))

Another possible serialization is using bytecodes, for a stack machine

	ldloc b
	ldloc c
	add
	stloc a

The above set of stack instructions can be easily decoded back into its original form (see drawing above). This is what the Mono JIT does: it transforms its input CIL bytecodes into various trees like this (we call these the forest of trees):

(stind.i4 regoffset[0xfffffff8(%ebp)] (add (ldind.i4 regoffset[0xfffffff4(%ebp)]) 
				      (ldind.i4 regoffset[0xfffffffc(%ebp)])))

The above if the debugging output that renders our C-based trees. We then use a code generator generator to transform the high-level operations (not listed in this example) into a list of low-level instructions:

        1  loadi4_membase R9 <- %ebp
        2  loadi4_membase R10 <- %ebp
        3  add R8 <- R9 R10 clobbers: 1
        4  move %eax <- R8

Depending on the optimizations turned on, there might be other steps involved, the end result is:

	mov    0x8(%ebp),%eax
	mov    0xc(%ebp),%ecx
	add    %ecx,%eax

(Actually, I had to trick the JIT compiler into doing this, because dead-code elimination and inlining in Mono eliminate redundant code).

Scripting languages

Now, am interested in this debate, because I think that Mono and the .NET VM are ideal virtual machines for scripting languages. Since the .NET folks have done a fair ammount of work into the interop issues (The Common Language Specification) and it is a fairly advance virtual machine, my interest is making Mono a good host for those languages.

It has been said `.NET works great for static languages, but not for scripting'. Which is not true; VB.NET and JScript are both dynamic languages that happen to work just fine on the .NET Framework. And we are convinced that the virtual machine can be improved.

The main issue we have today with Mono and scripting languages is that nobody has done a quantitatie study of what are the performance problems of running a dynamic language in the .NET/Mono CLR: Without an attempt to have a native compiler for the platform, and studying the problems, it is not possible to solve them.

In one particular case (Lisp), we know that implementors will likely want to structure their code (or their generated code) like this:

class Cell {
	Atom Head;
	Cell tail;
}

Method ()
{
	if (object is Cell){
		...
	} if (object is Atom){
		...
	}
}

So what they need in this particular case is a fast implementation of the `is' operator (the `isinst' instruction). For this, we did a proposal

Lots of Mono improvements recently; We released version 0.25 recently, which included plenty of the updates to the runtime and class libraries that were required by our partnership with Source Gear to run their vault software on Linux.

Still doing plenty of traveling, after the awesome GUADEC conference in Dublin, I visited Madrid fora couple of days, and then came to Mexico to do some paperwork. Will be flying to Oregon to the O'Reilly conference on July 8th

Will be on Mexico this weekend, and I get to vote (por the PRD of course)

Miggy went to Brazil, met girl, fell in love, got engaged.

Pictures are here, here, here and here.