Posts Tagged ‘coding’

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

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.

I’ve recently had a period where I didn’t do much else than writing unit tests. Instead of just writing them like a robot I tried breaking as much of the code as possible while getting our coverage percentage up.

There was one construct that kept coming back: Implicit comparisons. When I say implicit comparison what I basically mean is a comparison using a different comparison operator than ‘==’ or where at least one side of the comparison is an expression where not all possible values are meaningful.
//implicit
x < 8 //implicit
“ok” == IsUserLoggedIn()
//Not all possible values of IsUserLoggedIn are meaningful
//“I’m Santa Claus” for one is probably not meaningful.
//This also serves as an example of why not to represent state as strings

Sometimes the implicitness is hard to spot and sometimes the result of not spotting them might make the system rather vulnerable.
Let’s say that we in a system have a permissions check using an external method call GetPermissions().
Let’s assume that the possible values for PermissionFlags are None, Read, Write and Full (integer values 1,2,4,8).
GetPermissions returns a PermissionsFlags value.
The implicit comparison could then be similar to:
var neededPermission = PermissionFlags.Full;
if (neededPermission == GetPermissions(currentUser) & neededPermission) {
//Do something that requires PermissionFlags.Full permissions
}

The above code is pretty hard to test even though it’s only 2 lines, mostly because the “ugly” cases might not be easily spotted.
If GetPermissions behaves nicely it should only return even values from 2-14 or 1 but it’s external so we have no way of ensuring that it is well-behaved.

For uneven numbers the comparison might still work as long as it’s ok to ignore that the none bit is set high.
A value of PermissionsFlags.None | PermissionsFlags.Full is rather ambiguous but might be meaningful based on specifications.
What happens then if GetPermissions, when passed an unknown user returns -1 as an error code, expecting the caller to handle the undefined value?
The above comparison would then work fine for all known users but might (depending on how integer values are represented) return true for all unknown users

My point with this example is twofold. Always use explicit comparisons (especially in security code) and always return a well defined set of values or if the method is external always validate the returned values before relying on them being within certain boundaries.