Strangelights

Rico made some more interesting posts in his parser performance quiz, first producing a parser where the predicates are compiled into an in memory representation and also a parser where he produces IL on the fly. He talks about them here and here respectively.

So I ported both of these parsers to F#; as they demonstrate some nice uses of patterns commonly used in ML, such as take one data structure that is easy to read and transforming it into another than is easy to evaluate. This gives us 6 parsers in total, so wrote little test harness so I could hold a great parser shoot out. I had to alter Rico’s parsers slightly to fit them into my test harness, but the sprit of the code remains very much the same. All this code is can be downloaded here. I want to take a slightly more holistic view of things, so I’m going to take a look at three areas, the size, structure and modularity of the code base, the scalability of the parsers, and their speed.

Last night I too another look at my parser and unfortunately discovered some quite serious flaws in the algorithm, it was just too lazy and almost always terminated before it should. To fix these I basically ended up starting from scratch, I’ve reloaded the results. I’ll be tidying it up and talking about what went wrong as part of a wider comparison of all 3 parsers.

The snow is falling over Saint Germain en Laye and it makes everything look really pretty, but I have absolutely no whish to go outside, so I sit in the flat and what it fall and write this blog entry instead.

I’ve been following Rico Mariani’s performance quizzes for a while now and always found them interesting. The latest quiz on the performance of a parse, reminded me of a famous CS quote that every large software project has badly implement lisp engine in it. However I know little about lisp so I thought I’d have a stab at reimplementing it in F#. OCaml, the language that inspired F#, has a reputation for being as fast as C++, so it would be great if F# could gain the reputation for being as fast C#, so that in mind I setout with ambition of beating Rico's implementation.

Today was I was on holiday, doing a « faire le ponte » between the weekend and the public holiday toussaint (all saints day). I had chance to get lots of little jobs out of the way, such as tidying the garden and making the Christmas puddings. In between that I installed Visual Studio 2005 RTM on my laptop as apposed to a virtual machine.

So I thought I’d also take some time to write up some notes on things that I have noticed reflecting over generic types in framework version 2.0. In, what I shall call for briefness, .net20 the instance property FullName from the Type class is sometimes null. At first I thought this was a bug, but there are a specific set of circumstances when it is null and a fairly logical reason for it being null. This is noted in this bug report; however I don’t think the bug report makes the reason very clear, so I’ll write my own explication.

This is an explanation of why the var “keyword” is like it is, and how this effects anonymous classes. I should probably point out I’m nothing to do with the C# design team, so these are merely my own opinions.

The var is all about type inference, it’s important to remember this is still static typing. The var keyword informs the compiler that it should try and infer the type of variable; if it can not do this a compile error is generated. One very important aspect of the var keyword is that it can only be used with local variables, and even then are a few cases that are not allowed.

Last night we ate at the palace kitchen, why? Because Don Box recommended it to us! And very good it was too, we enjoyed a nice bottle of west coast red wine, which even my French friend Eric thought was good.

Anyway when our small party met him he was in the middle of a discussion with another Microsoft guy about xaml. They were talking about the possibility of using xaml to generate in memory only assemblies, of course while this is fun it does raise all sort of security issues, so Don suggest that you could send the xaml to an indigo service and sign with the propitiate ws-* feature.

I recently started measuring what gets downloaded and this made me noticed that my AssemblyExplorer tool is still very popular. I found this a little strange as its hopeless out of date. Also, why wouldn't you just use reflector Anyway as it was popular I decided I’d revamp it, and sat down to do just that this morning. I successful completed the first stage of things, it now it works with the latest version of F# and AbsIl.

Updating it was a bit of a strange experience, the design of the application is a little odd because of some limits that F# doesn’t have any more (and perhaps a few that I just imagined it did). It was so much easier fixing the problems with the app was so much easier because of the visual studio integration. Some of the comments are still misleading, so don’t pay too much attention to them if you do down load it!