I’d like to announce a project of mine that has been in planning since the end of January 2010: „TinCal“. It’s a project I’ve been working on and off (mostly off) for the past ten months, besides school, Prexonite and another secret project. At this point TinCal can really become anything from vapor ware to my next „successful“ (i.e. finished) programming language (and maybe bachelor’s thesis). So yes, it is a programming language and thus the successor project to Prexonite, and as before, I’m aiming much higher now. TinCal is definitely going to be statically typed and compiling directly to Common Intermediate Language (.NET byte code). But I don’t plan to stop there: True to my love for functional programming in general and Haskell in particular, TinCal is going to be a language extremely similar to the most successful lazy programming language to date.
The ultimate goal would be to actually implement the Haskell Report, though we’ll have to see if that is feasible with the chosen backend. The Common Type System is not as powerful as Haskell’s, type parameters must have kind *. This makes it for instance impossible to define the monad type class. The compiler will, at some point, have to resort to runtime checked downcasts. Fortunately, the core of the Haskell language is relatively small (especially compared to something like Java, C# or F#).
Apart from being “the next big thing”, TinCal also serves as a sort of “incubation project” for new techniques and technologies. For the first time I’m going to work with a completely immutable AST, no exceptions. While being tedious to program against in C#, it offers a number of interesting avenues. One idea I’m pursuing is to actually write a reference interpreter that operates directly on the AST nodes. It’s almost impossible to get such an interpreter wrong as the language semantics are more or less defined in terms of expression tree transformations. Once that works, I can test subsequent implementations against this reference interpreter.
But there are also other novelties in TinCal (at least for me). Static typing, type inference and whitespace-aware syntax are the obvious ones. In addition and unlike in Prexonite, I’d like the compilation process to be dynamic and extensible. Ideally there would be no hard-wired pipeline of steps but more of a build system with targets/goals and transformations that can be used to achieve said goals. I’m considering the use of the Managed Extensibility Framework for that purpose. The ultimate goal is to allow staged compilation to become a natural part of the language. The strong type system is a very powerful tool, it should be used beyond keeping integers and floating point numbers apart.
I do not have a fixed time frame for this project, though for it to be (part of) my bachelor’s thesis, I would have to have a working prototype in 6 months. I’m not sure to what extent this is realistic, especially considering how long the development of Prexonite – a much simpler project – has been going on. It all depends on the progress I make after this semester in January/February.
And no, development in the Prexonite department is not going to stop – it is still the most rewarding project to work on. In fact, I’m currently working on a version I decided to call 1.2. It includes a major overhaul of some key components. A preview version of Prexonite v1.2 can be found over on assembla. I’ll discuss changes – some breaking – and the reason why it was necessary in a future post.