Abstraction Compiler Framework: Semantic Analysis Time

[Alexander Morou]

Over the past few years I've been working on projects associated to lexers, parsers and compilers and I've finally reached a point within the compiler project to start a general-purpose semantic analysis phase.

For those familiar with this process it's a fairly complex one which involves: identity resolution, type checking, flow-control checks for uninitialized variables and ensuring a method result for each code path. Due to the complex nature of the feature set it'll also involve LINQ rewrites, Lambda rewrites, Async and Iterator rewrites, and the list goes on.

This thread is a progress thread for that process. It'll require multiple passes and reconstruction of the statements/expressions within the object model as well as type rewrites to accommodate the aforementioned feature set.

Since I know these concepts in theory but not practice, it should be interesting to see what results.

Current progress:
Structure Analysis - Analysis of the structure of the framework to determine the best course of action, it's pretty large.

 

[e]

I recently finished a course on interpreters (focus on the theoretical aspects of programming languages, such as bi-directional type-checking, unification and resolution, scoping, etc.), and I highly recommend looking into functional programming languages such as any in the ML family, or Brigitte Pientka's Beluga language. Most of these languages provide extensive theoretical information which might provide insight into how they are designed. Considering quite a number of parsers, lexers and interpreters are implemented in functional programming languages, I think it'd be worth looking into. I had to do a simple one, but I modeled it after Lua, which is tiny and very well designed (for its aims).

If you look into the Beluga page, they have quite a number of interesting publications about how they designed their language.

 

[Alexander Morou]

While I like the idea of researching new methodologies, at present the foundation which describes the high level structure of the code is already written in C#. Due to the complex nature of the meta-model associated to .NET types and the slightly higher level I placed it, rewriting at this phase wouldn't make sense. There's three different variations of the type model: Abstract, Compiled and Intermediate.

The abstract model unifies the Compiled and Intermediate models under a common construct to ensure that you can use any type regardless of whether it's compiled or not (guess that's the point of any object model abstraction.)

As for bidirectional type checking, from what I understand about type inference the context information associated to a given guess needs to be propagated as both a result and as context information inside the body of say lambda expressions. Especially important when you're making guesses to inferring the types of the parameters of a type-less injection, the actual members of and general use (through subsequent calls) of the parameters can aid in individual parameter type determination. That is, of course, assuming we're talking about the same thing. I'm working on a lot of this as a self-taught student of computer science, so there's a chance that much of what I know is downright wrong conceptually. I might not know how to read most articles on the subject matter due to lacking understanding of discrete mathematics and CS specific derivatives, but I'm certain that when I'm done the code will work, though I might not always get it right the first time.