|
I have been playing a little bit with our C# to Nemerle code converter. The tool created by Bartek is still under development. It sometimes produces code, which needs some more tweaking to compile silently with ncc, but it is already quite powerful.
As a life test I tried converting positive test-cases from Mono's C# compiler test-suite. I took quite behavioral strategy: do not touch neither original C# code nor produced Nemerle programs, just test. I was wondering how much I can get with this and today I reached the number of 200 working cases from over 600 original ones. Note that they are probably not the best examples on HOW to program in Nemerle. ;-)
Quite nice I would say, taking into account that there are some features, which we do not support (unsafe code, iterators utilizing yield, etc.), unstable state of the converter and the fact that test-cases are mostly malicious programs, which used to crash mcs. The most problematic currently are the tests with implicit conversions, which will be supported in Nemerle only with the new typing engine, which Michal is currently working on.
The problem even with working cases was that our testing program does some more checks when executing regression tests. I had to provide output for many of them and mark / fix warnings issued by Nemerle compiler (mostly about unused variables). But at the end it was fun to see a few more hundreds of 'Testing blabla.n...verify...run...passed' lines during our nightly builds. One nice thing about compilers is that they are text to text tools and are quite straightforward to test (given that you have good test-cases).
The tool will be included in our next release. Of course it's better to write Nemerle code from the very beginning using all its unique features. But in case you are not familiar with the new language and have some medium sized application in C#, it can help you dive into functional programming more easily.
One of the issues I have found annoying during this work was that we emitted much unnecessary meta-data information to the assembly (it posed some problems in custom attributes tests). So what and why was that?
You must remember that Nemerle has features not always fitting into .NET model and that it supports parametric polymorphism (aka generics) on 1.1 .NET framework (like Java 1.5 on its generics-lacking runtime). So, they can live safely within compiler, by to be able to create and load Nemerle assemblies without loosing information about special types and generics we have to encode them somehow in assemblies.
.NET custom attributes come very handy to do this. For example if we have
we encode them to something like:
This way we can easily recreate what Tree is and what is the type of foo function after saving and loading of code to assembly.
Now, what was the original problem with polluting meta-data? We were emitting those special attributes for every member of every class. So even if some field had type int, which is simply expressible by System.Int32 we produced some extra info to be consistent. Optimizing those cases resulted in some performance boost and a very nice thing - Nemerle produced assemblies are now basically not distinguishable from csc or mcs generated ones, if you do not use any Nemerle specific types.
After we implement the usage of runtime generics, this will be the very common case. For example functional type 'a -> 'b will be translated to Func1 <'a, 'b>. This is what I understand by multilingual platform (ignoring many of its tweaks, about which we might tell later) ;-)
-- Kamil