Every now and then (usually after something bigger gets finally implemented) comes the time to perform a “maintenance round” to clean up and finish the latest added features. That’s essentially what I’ve been doing lately. I want to keep it clean and tidy. I also thought that now would be the appropriate time to transform the compiler into what it’s intended to be in the end: a working console application. Until now I have had the input file hard-coded as well as the function call, to perform the actual compilation. Well, not any more. The compiler now gets called by commandline which defines all input files and/or additional options. All passed files then get parsed and compiled nicely one by one. The compiler will not be a DLL (as hinted in the previous blog entry) nor will there be any visible Windows form. There will not be a progress bar. Instead, the compiler does write some info to the Standard Output Stream – which can be directed straight to the future-coming CoolBasic editor. Possible compile time errors can be parsed from this string data. In addition, the compiler returns an exit code back to the system which tells was the compilation successfull or did it fail. Overall, this resembles how Visual Studio performs building.

I also took another round of standardizing the error messages (mainly those that get generated by Pass#2). Currently, there’s a great deal of them, and I estimate there to be a few hundred of them in total by the time the compiler will be finished. And I must say… Oh boy I’m going to be loosing some hair in an attempt of localizing them into finnish. Not because of the amount but because of their nature. The quantity of the finnish literature in modern computer programming is way below the levels when compared to other languages. Most books about programming are nowadays almost always in english which means that the finnish terminology is in danger of not being able to develop accordingly to the rules set by this industry. The impact is already very visible, and personally I’m going to be a little worried about the future-coming finnish localization… I think I will need to simply come up with some new terminology translations because there simply aren’t any established “official” words for their original english counterparts. This means that most translated terms sound silly because everyone is already used to their english meaning. There are some error messages that I already find difficult to properly translate into finnish. For now, I haven’t yet implemented the finnish translations although the support is there: someone would just have to fill in the missing strings. Well, maybe I’ll just delegate the job to someone in the devTeam later 🙂

I have finished the “maintenance round” now, and the compiler application is now operating well. I even tested running the compiler from within a .NET application, to receive its stream output. Please note that the compiler is still missing a lot of its functionality, and is not by any means, finished; It’s not yet able to produce the IL from the source code – which is pretty much the only thing remaining. Yes, the end of the tunnel is already visible, but there’s still a long walk before we reach it. I freshly added a new functionality to Pass#1 to gather detailed list of code lines and the exact method they belong to. Actually, I already had that data, but this modified collecting process gets the job done better. I now have a list of “executable code tokens” that need to be analysed for the final time, only this time we can be sure that their syntax is already OK. Practically, we’re cleaning it up, adding the needed metainfo, and dismantling it into fundamental theorems. Think about the For statement… it’s actually a While...EndWhile block.

So there’s only two major things remaining… the IL and the compiler Backend. Wow.

I’ve been working hard on CoolBasic V3 for the past few months. I have a regular job (as a programmer), so development time limits to weekends, evenings, and nights. Basically, I spend around 4-5 hours on average developing the CoolBasic Compiler every day, 8-12 hours aday during weekends and hallows. That being said, I thought that some vacation coudn’t possible be bad at all… So I kept 4 “days off” during the Easter, trying to clear my mind. But still I’m getting the feeling that I’m slacking. I finished the Expression Processor the day after I returned. As you may recall, I characterized this entity as for being the most complex procedure of the entire compiler so far. I’m very pleased that this enormous job is finally done. A few small things still remain to be taken care of, like handling access to Shared members and verifying legal type casting, but the outlines are now solid and the system seems to be working with the current (fairly sophisticated) algorithm.

There’s also something special worth mentioning: While I was creating the latest back-up copy, I noticed that there’s now exactly 1 Megabyte of pure source code. That means roughly 1 million key strokes! To visualize, count to 100 in your mind as if you were typing relatively fast. When you’re done, imagine to do it again for 10,000 more times! Yep, that’s a lot of code! Now, one could think that this can be explained with extensive copy-pasting, but that is not the case; in fact, the compiler architecture is designed to make extensive use of functional approach, meaning that practically speaking all of the procedures are so specialized that they don’t recycle code at all.

To illustrate, remember when I said that the type resolver and the identifier resolver would look alike and function similarly? That was the assumption I had before I actually got started with the Expression Processor. Well that assumption is no more, I turned things pretty much upside-down (there’s a lot more into it for the Expression Processor when compared to the Type Resolver where certain assumptions about the expression’s structure can be made). To sum up, Type Resolver is now fully operational, Name Resolution is now fully operational, Overload Resolution is now fully operational, Constant Value pre-calculator is now fully operational, and semantic checks are nearly finished. I’m also testing an idea of my own, to solve the grouping issue explained here.

EXE or DLL?
One day I was pondering which way would be better. The original approach was to make the compiler a Dynamic Linked Library, but bundle it with a Commandline Compiler (which would ultimately call the DLL anyways). If one wanted to create, say, an own IDE – or just access the compiler without CoolBasic being fully installed, there would be 2 choises depending on the situation and personal preference. However, a DLL cannot write to Standard Output Stream (well, this is actually not true, but there’s another reason why it’s a bad idea to try doing that), so compiling progress would have to either be completely silent, or the compiler would have to create a window equipped with a progression bar or at least a label with a description. Also, what *if* the compiler would crash (which of course doesn’t happen)… the entire IDE would crash, too. On the other hand, A DLL function could return a string with embedded metainfo about the end result whereas an executable can only return an error code back to the system. And then there’s the unpredictable memory and resource management of an attached DLL. Even though the CoolBasic Compiler is very well designed to free all resources after compilation, I’m still hesitating. A safe executable just ends, freeing all reserved memory 100% guaranteed. Going always through the Commandline Compiler would overcome that problem, but what’s the point of a DLL then in the first place?

As it stands now, I think I’m going to end up with Commandline Compiler only (which the IDE will silently call, meaning no visible console window will be created). This way the compiler can message back straight to the IDE, as well as provide with a log file for more details. It will also operate in an independent manner and free all its resources 100% sure. Possible OS porting will be easier in the future, too. There may be some priviledge issues involved, but let’s examine those more closely when the matter becomes more relevant.

Closing words
I’ll tweak the Expression Processor some more by fine-tuning its functionality and fixing any remaining bugs. While anything can always suddenly arise, at this point I’m confident that I can soon start thinking of the next steps. That would be something like processing all those code lines that execute program logic, and to generate appropriate IL for them. I’d say we’re half-a-way into Pass#2 now (and yet Pass#2 has more code than Pass#1 has).