Can a statically typed language be developed with the DLR?

6
votes

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/

3
c#compiler-constructionlanguage-designdynamic-language-runtime
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. - user395760
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? - Kieren Johnstone
@KierenJohnstone the languaje that i'm trying to implement is Tiger, but a simpler version - Ariel
@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. - Ariel
@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. - user395760

3 Answers

4
votes

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.

3
votes

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.

2
votes

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