Pass#2 Semantic checks

Data type resolution works now in all cases (I’ve extended its capabilities since I last mentioned about it). A quick wrap-up on Pass#2 would go as follows: Before anything can be calculated – including constant expressions – the compiler will first need to resolve the data types of all identifiers. In practice, this applies to variables, constants and procedures. In the other hand, in order to make type resolution fully operational, all alias names need to be resolved beforehand. A “type” here refers to a structure or a class. Also, “name resolution” in general refers to both type resolution and normal identifier (that generates a value) resolution. These two resolvers greatly differ from each other, thus I need to implement them both in such way that they operate independently from each other – excluding the fact that the identifier resolver may call data type resolver when needed. Anyways, the type resolver must be implemented at this point whereas adding value-generating identifier resolution just isn’t possible yet.

One could wonder why can’t I start working on normal identifier name resolution now that type references have been resolved. In OOP there’s a lot semantic checks that need to be done before resolving identifier references because otherwise you would get possibly misleading errors during compile time. Those semantic checks couldn’t be done in Pass#1 because data types weren’t resolved yet. The checks include base class checks, inheritance checks, override checks, and some special rules – only to name a few. Basically the compiler iterates the symbol table here, and performs a symbol-specific set of checks. All of these checks are not mandatory in order to produce a working executable, but they’ll ensure that the source code is overall valid and semantically correct. For example, a semantic error within a base class may not occur if name resolution returned a valid reference before that.

I’m going to remove part of the ambiguous name checks in Pass#1. Procedure signatures were formed in Pass#1, and they were used to check for identical overloads. Unfortunately, qualified names can bypass these error checks, so the signatures need to be checked again after type resolution. I could let those checks be as they are, but I’d like to shift these checks over to Pass#2 semantic validator so that they appear in one place only. With small adjustments to the type resolution, I think I can cover overloads much better overall. Overloads don’t apply to functions alone anyways.

I think I can finally get started with the most complicated sub-routine of this entire compiler (Expression Processor) once I finish with these semantic checks. As a side-note, I estimate CoolBasic V3 compiler is way past the halfway now. First things first, though – let’s get these semantics over with.

Sneak Peek: CoolBasic V3 manual

In parallel to compiler development, I have been designing the future-coming CoolBasic user manual for the past few weeks. I still use nearly 100% of developing time on the compiler, but the technical solution for the user manual is something I should keep an eye on as early as possible. Nothing too fancy, but I think it’s decided now how I’ll implement the manual (I have a working prototype already). Just like in the current version, the new manual will also be based on webpages. The exact same manual will be accessible both online and offline. You will be able to choose which version is the default when you access the manual from the editor. This way the end user can see always up-to-date online version if he/she chooses so, although the offline content will be updated regularly as well. It’s still uncertain whether or not those users who have a forum account, could write comments on the online manual pages.

Since the exact same manual is also available online, I must ensure that it’ll render the same way on all of the popular web browsers. This has been given me some headache. The offline manual relies on Internet Explorer WebBrowser control anyways, but as it’s well-known fact, IE doesn’t really follow the standards very well – especially IE6! A fresh statistics on indicate that 1/4 of all Internet users worldwide still use IE6 as their primary web browser. Basically this means that the manual must support atleast IE6. This sets some limits and workarounds I have to consider when I design the CSS and the dynamic functionality for the manual. I test the manual with IE6, IE7, IE8, Opera 9.6, Opera 10, Firefox 3.0 and Safari 4. For some reason, I couldn’t be arsed to install Google Chrome yet. Also, comes to good use.

There’s always atleast one browser that fails to function like the rest. IE defines its own standards, naming attributes differently in javascript. Some browsers just function differently in some javascript cases, for example the “name” or “id” attributes combined with “getElementByName”. Frames render differently no matter how you define the borders. And then there’s Firefox that refuses to disable escaping in XSLT despite all the whine that has been roaming for several years now. Due to all this, I had to write some “hacks”. But atleast it works now. Why can’t all browsers just follow the darn standards! Why must they define their own rules that only apply to them and not to any of the rest!

Enough whining, let’s talk about something else… like the looks of V3 manual! There will be a treeview. The manual will be hierarchical. As opposed to the current manual, you can now see the entire path to the currently open page, as well as easily change to other articles that belong to the same context. The treeview operates in an intelligent manner, making sure the expanded listing will not grow too big; only the relevant contents will be shown, the rest of the pages always remain collapsed. Some users, however, like to browse the treeview with several separate parent nodes open at the same time. This isn’t possible because of the intelligent collapsing (and it’s intended), so to help browsing back, there is a “breadcrumb”-like collection of recent pages at the top side of the manual. This collection updates dynamically, reorganizing itself so that duplicate elements don’t appear.

The color scheme will probably be the same as the current placeholder website (it looks so cool) with black background. I’ve made some minor improvements to the style sheet so that the layout fits better for manual pages. Captions will be aligned to the left, and their colour is now Orange. Links will remain blue. Text is still light silver. Emphasized text is now bright white and bold as opposed to current orange colour. In other words, every colour has it’s own, unique meaning. The test pages I have look very good at the moment. I also tried pastel colours with white background, but somehow it doesn’t look as good. The code editor will have white background, but this doesn’t fit to the dark theme of the manual. Therefore I’ll have to reconsider the source code colours for manual pages. More about that later.

Although the prototype is there, I won’t provide a screenshot just yet. There’s still tweaking to be done. I’m probably going back to 100% spent developing time on the compiler.

Compile time error messages

It’s been two and a half weeks since the last entry. It may seem a long time without any updates, but I’ve been working very hard on Pass#2 during this whole time. I finally managed to establish the architecture for data type resolving and name resolution. I just didn’t want to express any thoughts on this highly experimental phase until the solution that actually works on all test cases, has been found. That being said, I’ve spent the last few days on small improvements and bug fixing. Also, this is a good spot to clean up the code and fine-tune the work done so far until I get started with the next big thing (which I won’t elaborate at this point). One thing that needs improving and what has been haunting me for some time now, is the way the compiler expresses compile time errors to the user. The coding has been so hectic from the start that even though the compiler is able to express all the needed errors, some rephrasing is surely needed. Especially for Pass#1 which features a lot of syntax checks, and thus a lot of similarly formatted error messages.

Current V3 compiler error messages
For reference, compilation stops to the first error occurred – to prevent further (possibly misleading) errors from a chain-reaction the first error might have caused. This is identical to how current CoolBasic and many other Basic language compilers report errors. If you have programmed in C and the related languages, you might be familiar with the error flood you get when you try to build a project that had maybe just few small mistakes in the source code. In most cases, the tail of that list consisted of completely mysterious errors, and only because of the preceding errors caused flawed compiling process to proceed until the compiler got too confused to be able to continue. Luckily, compilers have become more intelligent regarding this matter, and for example, Visual Studio is able to construct a list with only the essential errors in it. CoolBasic V3, however, will continue to terminate the entire compilation on first error because of safety and stability. The sooner you get back to fixing it, the better.

Back to the current V3 implementation. To save time, errors are returned as strings when they occurr. I didn’t want to gather the absolute list of Pass#1 errors beforehand because it would have changed anyways. This was fully intended at that point in development. However, now that Pass#1 is essentially finished, I know all the errors that can occurr within it. And there’s now the need of rephrasing which means I would have to Find & Replace them all. Instead, it’s better to standardize the messages by binding them to constants; rephrasing them would require the change to be made to one place only. This need was also foreseen, but now it’s time to implement it. I would have changed the error message generation anyway, but this is also a great opportunity to think over better ways to express errors in terms of how they are phrased; Currently there exists a few vague messages that don’t provide enough information. For example, what does “Statement out of context” tell to the programmer?

The ideal error message
A good error message is uniformal, informative and precise. It should also provide a hint on how to correct the error. That way the programmer doesn’t have to visit the manual or spend time to understand what the error could mean in that particular case – which improves productivity and overall relish. However, being able to tell the error line, code module, the cause and the possible error code for further reference, is not enough. What if you had separarate statements written on the same line (separated with : of course), and you got an error saying “Error at line bla bla in code module bla bla: This statement cannot appear here.” More unnecessary time trying to figure out which statement caused the error. From my point of view it wouldn’t be too much of a work to bother adding this information to the error message, but omitting it would surely add up when hundreds of end users write programs in CoolBasic every day. Picture this: “Declaration context of ‘Const’ is invalid.” Sounds better? Sure, but something is still missing.

Normally I would add a hint on how to correct this error by specifying where constants are allowed or where they cannot appear. In this particular case it’s not that simple, because even though constants can appear within procedures and blocks, they can’t appear within Property or Select statement bodies. Rephrasing this error to cover exact definition where a constant can be declared would result in too complicated error message. Uniformality excludes me from listing the legal declaration contexts as well because their exact contents can vary depending on the statement. Compromises do happen.

Precise error messages also tell meta information about the error. For example, a vague error message like “Identifier is already defined.” doesn’t really tell which identifier is causing the conflict. A better version could be “‘myVariable’ is already declared in its context”, but it can be improved even further, providing more narrowing information: “Variable ‘myVariable’ is already declared in this Class.” – or even by providing the full declaration information, including the data type definition.

Whereas “precise” refers to “contextual detail”, informative errors specify moreover what’s syntactically or semantically wrong. For example, instead of telling “Syntax error. Invalid statement.” you could specify “End of statement expected.”

Detailed error messages tend to increase their amount. That generates variance which easily gets out of hand. Thus, even though you have practically different error messages for telling how different kinds of identifiers conflict in context, or what token statements expect next, they should follow the same basic formatting. This will not only result in impression of quality to the end user, but also makes the developer’s life easier in the future. Uniformality also emerges within the error codes. Even though variables and constants generate slightly different error messages when, say, their data type could not be resolved, they still share the same error code because the error occurred from the same cause. In other words: Error codes are not tied to the actual (unique) description. Something I need to keep in mind…

Showing the error to the user
The current CoolBasic version shows errors inside of a modal window with the code and description in it. Because of its modal nature, you must close the window in order to edit your code. And not only that, you can’t do anything while the windows is there so you *need* to close it. Does anyone else sometimes forget what the actual error message was, while you’re thinking and fixing? Well, I do, and it’s irritating when it happens because I will then probably compile it again to see it. Also, I don’t want to hear the Windows’ exclamation sound every time the compilation fails. In addition, there’s a known issue of Scintilla sometimes invalidating its rendering area when a modal window pops up basically making the source code invisible for quick inspection while the error window is present. So I’m experimenting with an idea to leave the latest error message visible to the bottom section of the editor, in a similar way than Visual Studio does. Also, when you click on that section, you could open the manual page for more details. You could even filter that section to show full error history or the latest error only. The error message should also be easy-to-read meaning that the error module and line number should appear in, say, inside their own respective columns.

The principle is that errors should be silent, but noticeable. And they should not create any unnecessary stir or require actions from the user.

Localize the compiler too?
I have mentioned several times that CoolBasic V3 will be fully localized into both english and finnish. This includes manual, website, forums, editor, tools, examples, tutorials and all of the content in general. There has been one hesitation to the rule, however. Normally compilers don’t get localized. It’s just the way it is, and nobody really questions it. Due to absence of real life examples and “significant” products pioneering this concept (To be honest, I don’t know about Visual Studio. I’m too lazy to check it out, but I haven’t heard about such thing), and combined with the amount of the required maintenance or the infrastructural problems within the compiler’s architecture, the idea hasn’t really catched on. Parts of the error messages would be in english anyway because common base class libraries are mostly coded in english, thus their identifier names mix to the localized language, making it look funny.

With all this rephrasing going on, it’s possible for me to build support for both english and finnish error messages. And I have decided to give it a try. You can always disable it, right? However, I will probably use english as the default compiler language even for localized CoolBasic unless separately changed from the editor’s settings.

The changes brought up in this blog entry will keep me busy for a few days…

CoolBasic websites now and in the past

The new website went online yesterday. As I mentioned in the previous blog entry, the old placeholder webpage needed to be replaced, because it wasn’t designed to last as long as it now seems it’ll take until launch of CoolBasic V3. It took me one day to build from scratch, but overall there’s much more effort into it. In addition to creation of the CSS-stylesheet and the HTML layout, there’s now a nice feature on the main page that lists recent forum posts and blog entries. Those listings required some manual SQL-queries for two databases on the web server.

I made some archaeological digging, and managed to find all previous websites of CoolBasic ever created (this is fun to watch). Let’s take a tour, beginning from the oldest:

Gigabot original Website, 2003

Gigabot original Website, 2003

First of all, those of you who are familiar with the history of CoolBasic, know that it all began off an idea of making a “programming game”. The game idea is simple – players would need to script an A.I for two bots. These bots would then fight each other, in an arena, and using an array of provided weapons like laser cannons and missiles. During the actual match, the players cannot affect how it goes. The bots simply rely on their A.I scripts until the other gets destroyed. The screenshot above is the original Gigabot homepage (2003). The game never finished (though I’ve thought about re-opening the project some day), but instead it evolved into something we know today as CoolBasic!

The very first website, 2004

The very first website, 2004

The first ever (official) CoolBasic website looked like that. Yep, it’s awful, and it’s from 2004 (Beta 1.0 release3). My www design skills clearly weren’t too good back then 🙂

The first 'real' website

The first 'real' website

Sadly, I couldn’t find this website anywhere. However, forum member Jare managed to find it from the Web Archives. I think it dates back to the late of 2004. It resided on a MBnet server which is a hosting service for a Finnish computing magazine, MikroBitti’s, subscribers. The current version was Beta5 (2nd re-write of the 1st generation).

Website for the current version (2nd generation), 2004/2005

Website for the current version (2nd generation), 2004/2005

The english website, 2005

The english website, 2005

Then there was the famous Blitz battle which lead to complete re-write of CoolBasic, introducing Beta 10 -series and the Object System. Also known as the current version, the 2nd generation. At this point, I registered domain, and factored a new website seen in the image above. The files date back to 2004-2005. At this point, CoolBasic also got some (unwanted) international attention which lead me to build a fast partial english localization of the manual and the website. The english support never got finished because of my famous take off, but proper localizatoin is something we’ll definately improve for CoolBasic V3.

The temporary placeholder, 2008

The temporary placeholder, 2008

If you haven’t yet read the previous blog entry, I strongly recommend to do so now.

When I made the come-back, CoolBasic V3 development was established (mainly because I realized how awfully outdated the Beta 10 was). The website was also totally out-of-standards, so I had to get rid of it as fast as possible. CoolBasic websites in general follow medium saturated colour theme. This “placeholder” was not an exception, but due to my mindset of “insignificancy” at that time, the technical aspect wasn’t taken care of in such quality I normally would have done.

The better placeholder, 2009

The better placeholder, 2009

This brings us here, the new “placeholder” website. I made an intrepid decision, and used black background this time, as opposed to pretty much any of the previous websites. A good website uses a palette of 3-5 colours to form its theme and feel. I picked yellowish orange and neutral blue that resembles the gutter bar of the current CoolBasic code editor. The orange is great for emphasizing text content, and blue would style all other elements that are not normal text, such as headers and links. The most difficult part was picking the correct blue hue because it easily banks towards cyan which is too bright for headers compared to the normal text, or dark blue which is too hard to read on a black background. Based on feedback, the colour theme succeeded; it’s easy to read, not too jumpy, and page elements stand out quite well. I’m glad to hear that 🙂

To enhance impression, I also did some artwork on the header and footer, to remind of a Game Creation tool here: This business is tied around entertainment after all. It’s not too obvious, but I bet it creates some subconscious images that support CoolBasic as a product. High-resolution textures and reflections create impression of the multimedia involved. And then there’s of course the never-dying logo of the “cool” Ice Cube.

There’s also some tech involved. I don’t have fancy ASP.NET support on my web server, so my options are quite limited of what comes to content publishing systems such as MS Sharepoint or Elevation. So I use PHP and MySQL. In this particular case, I had to integrate with phpBB3 and WordPress databases in order to compose a list of the latest entries shown on the main page. This is the first time I actually need SQL for my webpages, so I decided to do this properly and wrote a complete PHP5 SQL class (objects and classes are not supported until version 5) I can use for later cases, too. Those listings change according to the selected language of the website, too. I’m actually surprised that I managed to get this all running in just one day.

Now that I have stabbed both the official forum PHP code and the blog JavaScript code, I decided to establish a development environment on my laptop. Thanks to this “sandbox”,I no longer have to upload the scripts just to debug/test them. As a result I now have a complete copy of the forum, blog and the website, running on my localhost. All further development can be done locally on my laptop which is fast and painless. This gives me time to test things through properly before uploading to the production environment where the changes “go live”.

When I was digging for those old websites, I came across something that you guys have never seen before, but something that apparently was supposed to be the next CoolBasic website. In addition, there’s also a pic of CoolBasic’s supposed new manual front page. These files date back to 2007. Please note that these never went live, and never will. I have something completely different planned for CoolBasic V3 🙂

The unpublished CoolBasic Website, 2007

The unpublished CoolBasic Website, 2007

The unpublished CoolBasic User Manual front page, 2005/2006

The unpublished CoolBasic User Manual front page, 2005/2006

OK, back to Pass#2 coding…

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress