Posts Tagged ‘Compiler’

Just finished v0.2 actually there’s not that much new to v0.2. It simple adds a property production to the language as well. The syntax is similar to the one used in c#

A long the way I had quite a few strange experiences. The one that took me the longest to find a solution for was the fact that new LanguageCompiler(new Grammar()) (languageCompiler is a Irnoy class) ment to differrent things depending on how I used my compiler. If I used it with the Grammar Explorer from the Irony project or in the VS SDK hive everything worked fine, but using it stand alone to compile to a .dll new Grammar() suddenly turn it self into instanciating the Irony GRammar class instead of the PRoS Grammar.

Never figured out why but I can only say it’s a good thing to have the source code of the Libraries you’re using when you have to hunt down the reason to why they throw a null refererance exception.

Guess that the next thing I’ll include is a propperty setter or more advanced caching than the simple property


Well as I mentioned in Creating dynamic types in net im currently working on a language compiler. The language is called ProS. Thinking of it I might blog on the language name at some other point. The short version is that my thesis in compilers at Uni was called ‘ProS’ and whe I worked on the first version of this language I realized a lot of similarities to that project.

If you wander what happen to the first version: It died. My laptop died two days after I infected my back with Vira due to me making a backup of my moms HDD. Note to self. Use seperate backup media to own data in future.

The language is YANL (Yet anothe .Net language). you can write a program using the language only certain classes. I’m using dependency injection in all my projects and I’ve been using a few different and as noted in MAB ContainerModel / Funq: a transparent container most are painstackingly slow when it comes to creating objects. To me that’s a bit weird they are all used for just that!

The problem for most of them is that they are build on reflection. To me that’s two problems in one.  The main reason they are slow is due to reflection being slow. The second problem is that reflection is not safe.

(That is not entirely true:Typed Reflection but for the way reflection is used by ObjectBuilder, Windsor and similar the satement is true)

I like the way Funq mentioned above solves the problem with Lambda expression but I decided to take another approach to it by making a domain specific language to hanlde the injection. Basically what you can do is some thing like:

class Injector


constructor returnType GetMyObject([arguments])


//Here goes your dependency arguments

//Setting an argument named arg1 to 10:

//arg1 = 10;

//Then comes property setters.

//Same syntax as above



This will compile into a class named Injector with a set of methods called GetMyObject. The number of methods created depends on the number of constructors on the class returned by GetMyObject and the arguments given to GetMyObject. The arguments given to GetMyObject will be passed on as arguments to the constructor.

The result I expect is that this approach will be basically as fast as just simply calling the constructor. The method call is trivial and in the simple form is just one extra jump instruction.

The benefits of the ProS approach to the reflection approach is, not surprisingly, speed and type safty. After all that was my two main design goals. I’m very much looking forward to performing Daniel Cazzolino’s benchmark test to Funq and ProS.

Due to the fact that Irony and the Visual Studio SDK making it trivial to get highlighting, brace macthing and similar.  ProS comes with that as well.

Next step in the development is to take my version 0.1 and turn it on it self. Using ProS 0.1 as dependency Injector for ProS 0.2

A long the way I’ll make a few other features and add them to ProS v0.2.
A few of them are standard in most Ioc’s such as making caching possible but a few Is ProS only. One of them I had a lot of fun with when building version one. Making the Compiler plugable.

I’d write a post on  making the compiler plugable. For now I’ll just stick with saying it’s fun but im affraid it’s also the option of potentially really weird coding.

Im working on a language at the moment, which i’ll blog more on later. During the development I came to a point where I needed to actually create assembly files to test the result of the compiler. I’ve writte a few compilers using Reflection.Emit before and I’ve always come to a point where everything seems to be working fine. Using reflection I can see all the methods and all the classes but when I write it to file. There’s absolutely nothing but the manifest.

I seem to forget the trick everytime. If the module name is different from the filename it just wont work. I have actually no clue to why that is. But I had the problem today and with one single change namely making the module name the same as the file name, I solved the problem. If you don’t need to save your assemblies to disk, your basically free to choose the module name.