Can a statically typed language be developed with the DLR?

Question

I have to develop a compiler for a statically typed language for .NET I'm considering using the DLR for this instead of building all the parts (Lexer/Parser, Syntax, Semantic, Code Generation).

Would the DLR fit well for this scenario? Or it would be better to build the compiler directly for .NET and avoid all the dynamic calls.

EDIT: I did implemented the language without using any of the dynamic expressions that the DLR offers, instead I used the other expressions.

After that I can say that is much better when implementing a compiler to target the DLR instead of IL directly. The generated code still will be very clean.

If you want to see some code check: tigerconverters.codeplex.com/

Goring

What advantage would you get? You need a lexer and parser anyway or you'll have no idea what the program tries to do. You have to define the syntax and semantics, and you have to check both during executing even if you make a from-source-interpreter - far earlier in a compiler. And chances are you have to generate some code for some reasons, although I've never created anything targeting the CLR or the DLR so I can't judge this. – Eakins

I'm greatly interested in this stuff. I've created a few toy compilers from scratch, tokeniser->parser->planner->compiler. One even built pretty comprehensive C#-like expression trees and chunky method parsing. What kind of syntax are you looking at? – Apologetic

@KierenJohnstone the languaje that i'm trying to implement is Tiger, but a simpler version – Goring

@delnan this isn't about what adventages, if making a new languaje for .NET doesn't mean anything to you, then what's the reason for the DLR to exist. New languajes could handle better some scenarios, like Python, Ruby, Lisp already ported. – Goring

@Ariel: The DLR exists for implementing dynamic languages. If it was meant to ease creating compilers for static languages, it wouldn't be the Dynamic Language Runtime. At least that's what I gathered, hence a comment instead of an answer. – Eakins

@delnan But you can implement a static language compiled with the DLR if in the semantic phase do all the analisys, the problem is the DLR generated code vs code generated specifically for a static languaje. – Goring

Yeah. You can also compile Python code to a series of CPython API calls. But neither makes much sense. The main (or even sole) advantage of the DLR, dynamicness, isn't needed for such a project. – Eakins

Answer 1

The best thing the DLR has to offer you in this case is expression trees. These are the same expression trees introduced for LINQ but they've been extended to support generating full programs. It's much simpler to generate expression trees compared to IL and you get a bunch of useful checks when generating the tree instead of hard to diagnose failures when you generate invalid IL. So you should check out the System.Linq.Expressions. To compile and save to an assembly you'll want to use LambdaExpression.CompileToMethod.

The only thing dynamic when using these are the DynamicExpression nodes which you can completely avoid.

Chelicera

Answer 2

The DLR provides a lot of infrastructure that is useful for static languages as well. For example, it has default implementations for binding method calls and overload resolution. This is fine if the semantics of your language matches the default behaviour.

Error handling might be a bit tricky, however. If a method lookup fails, for example, the default binders will still return a valid expression, but it will be the code to throw an exception...

The DLR won't help you with parsing or lexing.

There are other options. For example, you may want to look at the Common Compiler Infrastructure project created by Herman Vitter of MSR. This may actually be a better overall match.

Elder

The DLR is build on top of the CLR, so it offers a higher level of abstraction when generating code. The CCI also does this but i think that the DLR offers a higer level of abstraction, at the cost of generating Dynamic Code. What i want to know is: is this really worth it?? how would this affect the performance of the generated program?? Compared to generate the code knowing it is static. – Goring

Also the semantic analisys could be done before the code generation, and we could check things like method M() belongs to type T, and others. and then generate the code using the DLR. – Goring

The DLR works with expression trees. Any dynamic expressions are resolved when needed. (This used to be when the code was compiled, but now there's also an interpreter.) If everything is known statically, then you might as well generate static expression trees and compile those. You have to do the binding at some point anyway. An advantage of the DLR is that it makes it easy to do things like build a REPL. – Elder

Answer 3

You by the way need to implement you own parser for you own DSL (Domain Specific Language). The compilation can be relay on CLR, but not your parser. DLR or CLR will not make a difference in the sense of your actual question.

A useful link: Create a Language Compiler for .NET Framework

Buttery

I never talked about building a DSL, and there are tools that help with the Lexer and the Parser. ANTLR is one of them, with it you could build the AST and then use the DLR for the following phases of the compiler. – Goring

@Ariel: me too:) I'm saying that you can not avoid using a parser and do what you want only with DSL power. My last sentence saying actually that. – Buttery