Posts Tagged ‘.NET’

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

Advertisements

I’ve decided to write a post for if not all the incremental versions of ProS then at least quite a few of them. My goal is to make addition to ProS and the rebuild ProS using those additions. The reasons for this approach are mainly two. I get a good idea of what’s working and what’s not and I might just get new ideas a long the way.

Reading a book written by the team who originally created SharpDeveloper (an Open Source IDE for c#) I learn the concept of “eating your own shit” as they called it. The Search and replace functionality had been lacking and at some point they realized that the developer doing that part of the IDE was him self using UltraEdit (or some other tool) when he needed to search and replace. With that in mind they decided that going forth they could only use SharpDeveloper for their development.

It’s the same thing I’m trying to do here, though my goal is not to make a Turing_complete. Actually I’m not sure it’s even Turing incomplete ­čśë So writing all of ProS in ProS will not be an option.

The first version is little more than a configurable object factory. Except for things such as using, types and values there’s really only one contruct to the language: The constructor.

The cunstructor gives the option of creating what well end up being a method returning an instance of an object. The syntax is

constructor returnType Name(arguments) : objectType

{

statements

}

The constructor is a keyword say: “next is the definition of a constructor. arguments hav the c like syntaks: type name and multiple arguments a seperated by a comma.

Statements can in this version only be used for setting ctor (which is the term I’ll use for class constructors to not confuse them with ProS constrcutor and by the way the term class is intentional) arguments. A stament could look like

number = 10;

That would tell the ProS compiler that each time this constructor is call the value passed for the arument number to the ctor must be 10. The argument names must match ctor argument names as well, and there must be a ctor with a list of arguments that matches the total of arguments and statements.

A complete example could look like the below:


using
Irony.Compiler;
using
Motologi.ProSLanguageService;
using
Motologi.ProSLanguageService.Compilers;
alias
tokenCompiler = ITokenCompiler;


class
Compilers{
constructor
tokenCompiler Alias(AstNode node) : AliasCompiler {

}
constructor
tokenCompiler Using(AstNode node) : UsingCompiler{

}
constructor
tokenCompiler Argument(AstNode node, TypeEmitter typeEmitter) : ArgumentCompiler{

}
constructor
tokenCompiler ArgumentValue(int position, bool isForStaticMethod):ArgumentValueCompiler{
}


constructor
tokenCompiler Class(AstNode node, TypeEmitter typeEmitter):ClassCompiler{

}
constructor
tokenCompiler Configuration(AstNode node, TypeEmitter typeEmitter):ConfigurationCompiler{

}
constructor
tokenCompiler Constructor(AstNode node, TypeEmitter typeEmitter):ConstructorCompiler{
}


constructor
tokenCompiler Identifier(AstNode node, TypeEmitter typeEmitter):IdentifierCompiler{

}
constructor
tokenCompiler Int(AstNode node, TypeEmitter typeEmitter):IntCompiler{
}


constructor
tokenCompiler Statement(AstNode node, TypeEmitter typeEmitter):StatementCompiler{

}
constructor
tokenCompiler String(AstNode node, TypeEmitter typeEmitter):StringCompiler{
}


constructor
tokenCompiler Type(AstNode node, TypeEmitter typeEmitter):TypeCompiler{
}
}

That class declaration is the inner workings of the ProS compiler ver 0.2. The result is two classes. One is called Injector and the other is called Compilers. The class Compilers is what is directly defined in the above code. For each of the construct there’ll be one static method on the class Compilers. The method will take the arguments listen in the argumentslist for the constructor and will return an instance of the type specified after ‘:’ I.e TypeCompiler for the last constructor.

The Injector class is nothing more than a container. For all the constructs defined in all classes there’ll be an over over of a method called Get. In essence it’s a large factory that given an ID and a set of arguments will return an object.

In contrast with say Windsor’s ServiceContainer or similar in other reflection based frameworks the list of arguments is type checked compile type.

The approach of compiling the dependency configuration does impose some other (sometimes strange) issues. So the gain in type safety and performance is not for free. But some of those issues can be resolved with delayed compilation. So that the types mentioned above wont be created until runtime. I have a plan of adressing just that in a later version of ProS. For now I’ll dig into ProS ver 0.2 using the above configuration

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.