The ‘Classic’ compiler in C#
First things first: I’d like to correct the wording in one of my previous postβs statements. I mentioned this “another compiler that didn’t turn out that good”. Some people are now under the impression that C# is to blame for the project in question being now in a frozen state. Maybe I phrased it poorly, but the fact that it was developed in C# at first, has little to do with its failure. The author clarified to me that he dropped C# and switched over to C++ just for the sake of re-writing, and not due to performance issues. Personally, I don’t buy that, but that doesn’t matter. What matters is that a lot of people are paying a lot of attention to what I actually say, and I should be more careful how to express my thoughts in this blog. So let me emphasize once and for all… the other compiler project was ‘successfully’ developed in C#, and later in C++, but is now paused for an undetermined time due to completely unrelated reasons. There. Case closed. He’s watching my blog very closely, though π
And then onto other issues at hand. The new compiler (written in C#) is progressing nicely. In the beginning there’s naturally lots of plain setup to do just to get most of the needed entities created. It’ll get more interesting soon, though. For the past week, I’ve used approximately 4 to 6 hours almost every day after work to establish the new compiler solution. That’s a healthy 12-14 hours of programming a day π . Time flows easily when you listen to inspirational music. Currently, the compiler parses the command line arguments, initializes a build job, and invokes the lexer on the source file. Half of all token types are already recognized, and there’s also one dummy parser (which, for testing purposes, only prints all tokens to the console output). I expect to finish the lexical analysis on the remaining token types soon. And then I can start implementing the statement parsers – which ought to be interesting because I now have some new tools at my disposal, thanks to object oriented platform.
I decided to take a little different approach for error reporting. All old compilers shut down the process immediately after encountering the first compile error. This new design doesn’t do that, but the compiler creates a list of compile errors instead and prints them to the standard error stream. This allows Cool Developer editor to compose a neat listing the user can then iterate through and fix more issues at once before re-building. This will probably save time on trial-error, and thus enhance productivity. Basically, this concept requires the compiler to be able to recover from compile errors and simply continue the process from the next statement. Oh, architectural joy! In addition, the compiler now also supports warnings i.e. messages that don’t count as errors, but still hold information about problems in code. Warnings don’t cause the compilation to fail, but they too will be listed in Cool Developer’s user interface.
As a bonus, you’d call the CoolBasic Classic compiler from command line like this (subject to change):
cbccompiler mygame.cbc /out mygame.obj /def coolves.fw
You can optionally enable Finnish interface by adding /lang fi