Cool (Game) Developer

The new CoolBasic project is divided into several sub-projects. Each team member has been assigned to one of these projects according to their skills. This first half of the year has proven to be productive, and we actually have concrete results already. Most news has been posted on the Finnish forums, and I apologize to you non Finnish people, although we tend to evaluate things we want to share every once in two weeks, we’ve been quite silent about our plans and doings. The reason there’s been so little information in English is purely that we want to limit how the word spreads at this point in time – we all know what happens to too high expectations in the end. The Beta plan is to first limit it to a smaller closed group which makes possible for us to iron out the most critical bugs. After that we’ll extend the Beta program, ultimately for all. However, please notice that talking about Beta doesn’t mean it exists yet. We’re not there yet. In this blog post I wish to shed some light to the different aspects of the huge CoolBasic project. More details will follow in forth-coming blog posts, this is just a compendium.

Before we start…
At the beginning of June we had a public meeting to which nearly 20 members of the CoolBasic community participated. We rented a summer cabin for a weekend and headed to Nilsiä situated in middle Finland. Many of us saw each other in real life for the first time and had a chance to talk face to face. It was a bit rainy, but I at least wasn’t too sad about it – I think we all had a great time having sauna, barbequing some sausages, playing games, and having fun in general. Too bad it was only 3 days, but arranging the date so that this many were able to make it, isn’t as easy as it sounds. Half of the participants were in fact Devs from the team, and we actually had a presentation, powered by a video projector, to show off the new editor and engine features. More social meetings, please 🙂 There’s definitely going to be another next year!

The CoolBasic Meet 2010

The Editor
The old CoolBasic editor will be completely replaced with a modern project based development environment. This time we’re aiming really high, and this new editor, Cool Developer, is designed so that it can serve as development environment for future coming products as well! It’s highly modular and the architecture makes it possible to develop powerful plug-ins for it. We’ll probably even offer free Visual Studio templates for download so that anyone can develop a new plug-in (or an entire product, perhaps your own programming language) for Cool Developer. The editor is fully customizable and localizable, and it can dynamically load custom made UI modules on the fly. In addition, the way the editor looks, is fully customizable through skinning. I think we’ll go for cool black look this time 🙂 If you know XAML, it’s relatively easy to write your own skins. Skinning the editor, however, is not just defining the colors – it’s possible to compose everything, including layout, UI animations, and visual effects!

CoolBasic games are now created as projects that host all the related code files. Much like in Microsoft Visual Studio, project structure is a hierarchical list of all files associated with that project, including code, media, and other content. Those units don’t necessarily reflect the underlying file system at all, but the entire project is easily transferred between different machines by simply copying a single folder. You can also have several projects open at the same time, in which case the top-most element within the hirearchy is a “Solution File”. it’s basically a collection of different projects. Imagine you have a game (solution) that includes a CoolBasic Classic code project, and a Tilester project that has all the maps the game uses.

We’ll also construct a new “Start Page” that will list the most recently accessed projects, show you some news from the CoolBasic community, and perhaps feature some interactive content. It might even be possible for you users to customize the start page via XAML.

Everything, including the Start Page, manual, code files, and visual editors, can be opened into a tab. The behavior is much like in the current (obsolete) editor, only there’s no limit what you can open in a tab. We can even present complex editors, such as a tilemap designer, inside the editor now. Imagine a visual editor to build game objects, or a tool that packs game media in a compressed file! We basically associate some content presenter to a file type: for code files it’s going to be a syntax highlighter editor, for other types it’s going to be something else – a web browser for web pages, for example.

The editor also has a built-in update engine which keeps all installed products always up-to-date; you no longer have to manually download and install updates when we fix bugs or add new features to CoolBasic Classic compiler or the CoolVES engine.

As for the user interface, it resembles Visual Studio a bit, but we’d like to enhance it with some fresh ideas. It’s relatively rare, for example, a code editor to have a ribbon… or how about something completely different to the standard Solution Explorer + Property Window combination? A screenshot of the new editor will be provided later – there are a few things we’re experimenting at the moment. At this point, however, it’s looking really cool in its black theme! As a side note, the editor is currently developed by two professional WPF (Windows Presentation Foundation) programmers. And yeah, it’s in .NET Framework 4.0 🙂

Compiler & Language
Although we plan to design the language as similar to the old CoolBasic as possible, we’re going to make some changes to the basic syntax to accommodate “more accustomed” practices. For example the member access operator “” is going to be replaced with a dot. Custom typed variables are declared via the “As” clause inside a “Dim” statement. Arrays and Linked Lists will also see major improvements – it’s now possible to pass arrays as arguments, and return arrays from functions. Arrays can also be of any (custom) type. Linked Lists are no longer singletons based on a type i.e. you can create as many Linked Lists of any type as you like. There’s also going to be differentiation of Subs and Functions. We may also enhance the “If” statement chain. Structured error handling and a debugger are also considered. Of course, we’ll integrate the debugger to Cool Developer editor as well. All in all, most old CoolBasic games should be relatively easy to port and compile against the new execution engine. Simple find&replace throughout legacy code will probably not be enough, but the additional adjustments one would have to make manually are merely trivial.

CoolBasic Classic is producing CoolVES compliant byte code. This means that the game engine is separate to the language that simply is porting games for its use i.e. it might be possible to write CoolVES games in other languages than a BASIC in the future! Or having a completely visual game building tool (like Click’n’Play / Game Maker) for the CoolVES engine! Maybe CoolBasic Classic could even operate as the programming language for other execution engines as well *cough*.

The improvements to the current CoolBasic Classic compiler (taken from experimental code of the V3 compiler) have proven to be working well. The lexer and parser are already done, and code analysis is under construction. It won’t take long until I get to the synthesis part which essentially means, at that point, the compiler can actually produce byte code and the development of the CoolVES execution system can begin! That’s also when the cool stuff begins and the rest of our team members get their hands on some really nice stuff. Perhaps a public tech demo will follow 🙂

The Game Engine
Now the actual game engine is something that has made huge progress during the past few months. It’s going to be OpenGL based and cross-platform. Whereas the old CoolBasic only has software renderer, the new graphics engine is taking full advantage of modern hardware. The engine is already able to render game objects on to screen, and rotate, scale and transform them – basically everything one can already do in old CoolBasic. Blending with different modes is supported as well as different filtering methods. We’re even experimenting with some more complex materials. The game objects can now also have a parent so that they move, rotate and scale in relative to the parent object. In addition, we now have multiple camera support, and camera zoom and rotation! It’s probably a bit too early to talk about object animations, but we do have major plans to drastically improve it. Also tilemaps are going to go through lots of improvements in terms of rendering, interacting and collision checking. All in all, there’s a lot more you can do with game objects now, and the command sets are going to be re-designed from scratch.

As what comes to the audio system, we’re dumping integrated FMOD. It may become an option again later in the future (optional engine you could enable for use in the project settings within Cool Developer interface). FMOD makes it possible to use wide variety of different formats, and even visualize the output stream, but for now we’re going to implement the Audiere library which is completely royalty free for commercial and noncommercial use. As a side note, the primary recommended format all CoolBasic demos and tutorials will use, is going to be MP3.

Perhaps one of the most interesting new major features we’re adding, is the in-built game physics. Every game object can have full 2D dynamics applied to them. You’ll simply define mass and shape (amongst a few other attributes) for an object, and everything else is done automatically for you – objects will bounce accordingly from walls and each other. Implementing this powerful feature will enable the users to create games like never seen before in CoolBasic! This system also serves as base to in-game collisions, to make game character jump you only need to apply an impulse upwards. Should you hit your head to the ceiling, you simply drop down again, and automatically stop falling upon hitting the ground. Collision events can be queried; making it possible to fire certain animations in certain situations (crouch upon landing, for example). The physics naturally also apply to particles on screen. You can build more complex physics bodies by combining several existing bodies and you can create constraints to bind separate parts to each other. Perhaps a visual game object building tool for Cool Developer editor will be written at some point.

There are already fully working internal tech demos for the graphics engine and physics. No screenshots for now (as those demos in question render lots of test data on screen).

The Manual
We haven’t formulated full details yet, but a graphical design plan document already exists. As with the V3 manual, we probably won’t be implementing such deep tree view based document structure, but more like a mixture of old design and easier navigation through document pages. We have a few professional web designers in the team, so this time there’s going to be a lot more look and feel to it. While the manual will be written in both English and Finnish, in addition to comprehensive language and framework references, we’re going to focus more on complete tutorials and examples and even in social media and interactive content in general. You will be able to comment the pages, as well. Integrating the manual to Cool Developer so that the two work seamlessly together (in an attempt to provide studying material like never seen before anywhere else) is also one of our top priorities. We have some exciting technologies in mind on how to provide the best manual possible.

The Website
We’re aiming for strong user community. Integrating with the forums and blogs require custom code, and we’re currently building our own CMS (Content Management System) on the CodeIgniter framework. The amount of content we have planned for the new coming website is huge, so its management requires a CMS. It’s a bit too early to provide any screenshots, but the goal is to make the website such a place the users want to visit it in addition to just reading the forums.

Closing words
The information provided by this blog entry was intended to be a general peek of what different sub-projects are involved and what’s their current status. We’ll get back to details later. I hope this delivered some idea of how big of a project the new Cool Game Developing Environment really is. It’s not just CoolBasic Classic, but rather a whole base and framework for future work as well. We have regular internal meetings every other week, after which we normally decide what information we choose to share publically. Sorry for the long wait since the previous blog post, stay tuned.

The new parser is underway!

It’s been a bit silent ever since I finished the V3 compiler – oh well, kind of. Even thought the compiler was fully functional, I realized that it had to be re-written in order to gain more performance. Due to drastic syntax changes of the key elements I can’t copy-paste the previous code much at all. And, writing basically the same old code again is – big surprise – boring. I also finished my thesis so I felt complete, and wanted to take a few weeks off. I’ve been working hard one year straight after all.

So things have progressed a little slowly for the past few weeks, but at least they have. I didn’t want to blog until I had finished a certain feature, and that’s the support for conditional compiling. I demoed the feature in Assembly Summer 2009, but it has now been enhanced! Conditional compilation practically means that the programmer can affect at compile time which parts of the source code will or will not be compiled. Because CoolBasic V3 compiler optimizes all conditional branches, including If, While, and Until, by stripping constant expressions that evaluate to False, from the final Intermediate Language, the #If and If statements were essentially identical. However, conditional compilation now gets evaluated immediately after lexical analysis so that False branches don’t get processed in Pass#1 or Pass#2 at all!

These so-called directive expressions must evaluate to a constant value. Because the directive expressions will be evaluated before statement parsing, regular constant variables can’t be resolved. Thus, there will be no name resolution (as we understand it in OOP), but instead, CoolBasic introduces directive constants which can be declared via the #Const statement. These constants are separate from the regular ones you’d declare via the standard Const statement, and they will not conflict by name. Directive constants are always Private to the file they are declared in. In addition, it’s possible to define global directive constants at project level, but that will be a feature of the code editor.

In contrast to regular constants, directive constants can be declared multiple times with the same name, and it’s possible to assign a different value to them each time. You can use existing directive constants in directive expressions when declaring other directive constants. Imagine the possibilities for implementing different sound engines, for example. The following example will shed some light about the concept:

#Const DEBUG = True
    // This will get compiled, and is available in program
    Function A() 
    // This is unavailable in program – unless #Const DEBUG = False
    Function B() 
#Const DEBUG = Not DEBUG // Redefine the DEBUG directive constant

As directive expressions are processed so early, I had to write yet another postfix converter and calculator for the purpose. God that was boring. At least now it’s done. Next, I should be able to start writing statement specific parsers and general-purpose parsers.

I may (or may not) have a mega surprise next time. Stay tuned.

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…

Annoying syntactical exceptions

So I have been writing these Pass#1 statement parsers for a while now (a bit more than 20 more to go). Recently, I came across with the Declare Function statement. It’s responsible for declaring a function from an outside resource – for example, a DLL-file. The general guideline is that all statements would look the same as the corresponding statement in VB.NET. So I began the normal procedure I do with every new statement parser, i.e type in a sample code in a source file which will then be passed to the compiler. Now, the first thing to do is to enable the parser function in question and then create the parser skeleton for quick OK check. I was surprised to notice that the compilation failed due to syntax error before the code line got even passed to the main parser function. The VB.NET syntax is as follows:

Declare Function MyFunc Lib "System.DLL" Alias "_RealFunctionName" ( [params] ) As [type]

Now the general syntax rules define that a literal cannot appear just before an opening parenthesis. And well well, isn’t that a string literal and a parameter list just after. I was first like, WTF how can I “fix” this in a non-ugly way without breaking the general syntax rule set. I had three choises, none of which seemed good way to go:

  1. Allow a string literal to precede an opening parenthesis
  2. Allow a string literal to precede an opening parenthesis only in a Declare statement
  3. Alter the syntax of the Declare statement

Definately not Option 1. Option 2 seemed to be the best choise because I still did’t want to alter the syntax of the statement. But that would have been an exception to the syntax rules. I don’t like exceptions in any program structure, because in the end, it will make code maintenance messed up. I thought about pros and cons of options 2 & 3 for a long time. I could have added a small keyword between the string literal and parameter list. The resulting statement syntax could look something like this:

Declare Function MyFunc Lib "System.DLL" Alias "_RealFunctionName" Ansi ( [params] ) As [type]

…where “Ansi” could be, for example, a charset modifier (Ansi/Unicode/Auto). On the other hand, charset modifier is already an optional modifier in the VB.NET syntax; its place is right after the Declare keyword. CoolBasic won’t provide support for charset modifiers just yet (since it’s optional I can add it later on without breaking all existing CoolBasic source codes which would make users angry).

Another solution for Option 3 would be to define Alias as identifier instead of a string. The syntax would look something like this:

Declare Function MyFunc Lib "System.DLL" Alias _RealFunctionName ( [params] ) As [type]

It seemed like a good idea at first, but come to think about it the solution would be logically wrong. By definition, all identifiers should be usable by the programmer. In this case, the Alias identifier would not – or it would be unintended identifier reserving a name without real operational use. At this point I ran out of options. This isn’t by the best practise, but I decided to go for Option 2. Luckily I’ve designed the lexer to be quite flexible so I only needed a small change in one place, basically overriding a syntax error based on a simple condition of few preceding line tokens.

As a result, the syntax will be exactly like in VB.NET, as intended. Internally, the fix didn’t end up being as ugly as I had feared. Overall, I’m content with the outcome. Pass#1 continues…

CoolBasic Program Skeleton

The leap from a procedural language to an object oriented language is huge for both the designer (me) and the user. I have established the guidelines and practises how CoolBasic programs need to be built, and I’m already seeing light at the end of the tunnel (which doesn’t, however, mean that I’m nearing the end). From the user’s point of view the change is so big that CoolBasic V3 can be considered completely different a language from what it used to be. And it is. You are going to be writing slightly more code to achieve same results compared to the current CoolBasic (that never got past its Beta stage haha).

In OOP languages, all executing code must be written inside a procedure. I say procedure, because it’s a uniting term for Functions, Properties and Operators. This means that the main loop of a game must also be inside a Function. Since functions can only appear within the module context, you must define the containing module or class. You can’t call the starting code from outside, so the concept of Main Function needed to be implemented. What this means, is that you must always write Function Main() somewhere in your root level Modules. It operates as an entry point to your application. Only one Main Function can be defined. The concept is similar to .NET languages and C/C++.

It may seem like much, but in the end it isn’t. Sure you have to build all programs in a certain way based on a skeleton, but after that things get simplier. The following code demonstrates a simple HelloWorld program. It will require 11 lines of code whereas the old CoolBasic only required four lines. But you really can’t simplify things any more than that in the OOP world. This can be confusing to newcomer programmers, so perhaps when you create a new project in the CoolBasic code editor, this skeleton could be automatically typed in – for reference and easy start.

Simple HelloWorld Example

Simple HelloWorld Example

Please note that the example program above is subject to change, and is most likely not final. Most of the example’s code lines belong to the frame you need to define. The main loop is still quite simple. First we open a windowed game screen of 800×600 dimensions. Then we loop two lines of code (text drawing and screen updating) until the Screen is closed. The biggest challenge is to memorize all new classes and their methods. A brand new, comprehensive and user-friendly manual will help with this, and perhaps I’ll implement some kind of an intellisense-prompt to the editor at some point.

A short update on CoolBasic V3 compiler progress: The above example fully passes the lexer, and soon the parser (Pass#1) aswell. All in all, I need to implement the parsers in the same order as one would write code to a program; containers first and then the statements. It’s slow in the beginning due to the complex structure of, say, Function statements and such, but the rate should accelerate when I progress through the simplier statements in the end. I recently finished the Function statement parser which is one of the largest and most complicated parsers, and I feel good about it; solid ground is the key to success. I expect to implement the Class and Interface parsers in the near future.

Highly Modular

I spent most of yesterday sprawling on the couch thinking about the fundamentals of programming languages and how, for example, VB.NET has most of its modern features implemented. I came into conclusion that it’s absolutely necessary to discard the idea of one-pass top-down parsing when the symbol table is created. Most of the old-fashion procedural languages (which includes the majority of BASICs), scan the source in two or three passes, but always so that when a new identifier is encountered it must have already been defined; otherwise the compiler would report an “unknown identifier”, and the process terminates.

Since all code in OOP-languages must be written within a container (Module, Class, or an Interface), there’s a problem when you must declare identifiers with each other’s type. There are no “prototypes” to introduce identifiers before actual declaration. The following code illustrates the problem:

Class Class1
Public c2 As Class2

Class Class2
Public c1 As Class1

The old-fashioned compiler would stop at the 2nd line of Class1 because the abstract data type Class2 is not yet declared anywhere within the preceding code lines. Therefore we need two passes at the minimum when we compile the the symbolic table of the entire source code. Practically speaking, CoolBasic will still compile the symbolic table during the first pass, but some information of each identifier such as its data type doesn’t yet point to the structure of an identified data type. Instead, there’s merely a string-based reference, which will be taken care of in later compile parses.

Structure of a CoolBasic program
The ROOT level i.e source file context can only contain Modules, Classes, Interfaces and the Imports statement. The Module declaration context, can contain Classes, Structures, Procedures, Enums, and variables. Classes can contain Classes, Structures, Procedures, Properties, Operators, Enums, and variables. Structures can contain Structures, Procedures, Properties, Operators, Enums, and variables. Procedures and Blocks can only contain executable code and variable definitions. Those variables are considered Public, but local. A block can’t define a variable that shadows parent level local identifier. The “variable” here also refers to any Constant. Identifier match resolver operates in standard dot notation rules, but each Imports declares a special namespace. If an identifier reference couldn’t be resolved, the compiler will attempt to match it with these namespaces as a prefix of the identifier.

Minimum language feature requirements
Object Oriented Programming unloads some very powerful tools of which I can take advantage of in creating more sophisticated structures. As I was lying on the couch this huge idea came to my mind… could this be possible?! What if you actually wrote some of the very basic features of any programming language by hand… in CoolBasic itself. Things such as strings, arrays or linked lists. So I spent some time mapping what are the bare minimum requirements the language absolutely needs to support, in order to provide everything essential so one could write all other features that are considered “standard” in today’s programming languages. These are my findings:

The language must support at least:

Basic program flow, Modules, Classes (with full Inheritance support), Procedures, Declares, Structures, Variables, Constants, Properties, Operators, Generics, certain in-built Operators, The ROOT data type

Can be implemented later:

Imports, Interfaces, ForEach

Need to be implemented before starting to write the essential classes in CoolBasic itself:

Memory, Console

Can be written in CoolBasic itself:

Integers, Floats, Strings, Arrays, System services

Sophisticated features written in CoolBasic itself:

List, LinkedList, Stack, Queue

Game related:

Graphics System, Object System, Input System, Sound System, etc.

“Imported Packages”
I have this idea of “Open Source” where all these modules written in CoolBasic itself, come with the package. You can see how they’re done code-wise, and you can even modify or optimize them. These modules would be located in an “Imports”-folder or something like that. The compiler would automatically import the standard modules, but nothing will stop you from adding in your own modules and by using the Imports statement, include them into the compilation. There’s one down-side to that, though: It means that *everything* will be compiled *every time*, slowing the process a bit. One way of solving this problem, would be a support for pre-compiled libraries (CoolBasic-made of course), but I need to do some more research about that.


As a new feature, CoolBasic V3 will support class properties. You may have already seen a hint for property support when I discussed about the String implementation earlier in this blog. Properties work just like any other Public variable, i.e you can access then by using the dot notation, but with a added twist. Normally, when you either assign or read a value from a Public variable nothing else will happen. But with properties you are able to capture this event, and execute your custom code to get the job done. Basically, we’re talking about old-fashioned way of creating getter and setter -functions. Without properties you’d have to write these two functions in order to access, say Private variables:


With properties you could do the same in more decent way:

MyClass.Name = "hello"

You still define the getting and setting code within the property structure, but done so they’re unaccessible from outside. So you have nice little black box of which workings not even the class members know about. There’s a difference in using the property name than assigning the value to the private variable in question by hand – even when all the setter does is the assign. There’s always code involved when accessing property values.

In addition you can define the property as ReadOnly or WriteOnly. By doing this, you protect some data that must not be modifier from outside. One example of a ReadOnly property would be the length of a string. The property returns the value of a Private variable, however this information is related to the actual data within the String class, and should only be updated when this inner data changes. It’s the only way of keeping such information in sync in a secure way. Now if you come to think about it, constants are ReadOnly, too (except that CoolBasic compiler doesn’t work like .NET compilers in this regard).

Since properties are really a set of methods, they can be inherited. This also means that things like overriding, are possible. However, at this point in time, I’m still a bit unsure about one thing called Default property. A property can be defined as Default when you access the object without providing further dot notation. Sound like normal object reference? Well, there’s a catch. In VB.NET Default properties always need atleast one parameter which means you must include a set of brackets to it. A typical example would be the myVar.Item(index) property you could refer to just myVar(index). I don’t like this because it’s easy to mix this to a method call.

On the other hand, I would still have to allow parameters for properties because it’s the only way to implement indexes to them. Like above. If I ever wanted to implement LinkedLists or Lists or any variant, I, in fact, must allow this. There are still lots of questions floating I need to chew on.

Scope rules in CoolBasic V3

Warning, wall of text incoming!

“In computer programming, scope is an enclosing context where values and expressions are associated. The type of scope determines what kind of entities it can contain and how it affects them. Typically, scope is used to define the visibility and reach of information hiding.”

The scope of an entity’s name is the set of all declaration spaces within which it’s possible to refer to that name without qualification. In general, the scope of an entity’s name is its entire declaration context; however, an entity’s declaration may contain nested declarations of entities with the same name. In that case, the nested entity shadows, or hides, the outer entity, and access to the shadowed entity is only possible through qualification.

So much for theory (the quoted text was from Wikipedia). Now, what does that mean for CoolBasic…

In VB.NET and C# there are mainly two kinds of scopes: We have a root/namespace/class/structure context, and then we have a method/block context. The main difference between the two is how data can be referenced in Object Oriented Programming. Class instance variables (objects) store their values in heap because they are reference types and their life span is not determined beforehand by the compiler. Procedure variables, however, store their values in stack. It’s a static space in memory where procedure variables temportarily reside, but from which the space is automatically freed when the life span of all those variables ends, i.e the procedure exits. Because of the stack, recursive calls are possible.

It’s important to realize that the program structure is highly hierarchical in Object Oriented Programming. It’s all about references to other objects and their parent-child relationship. Gone are the days of procedural programming and direct function calls where the only way to share data between two functions, was to introduce a global variable to hold that data. Now, global variables are quite bad a concept and frowned upon by most programmers today. That’s because in general, it’s often difficult to keep track of the value of a global variable plus all entities that can modify it. In the end, there’s more cons than pros when we’re dealing with large and complex projects.

I will not talk about global variables (or the lack thereof) just yet. Nor will I define concepts of Inheritance, Shadowing or Overriding because in all probability I’m going to do so at some point in future anyway. For quick reference, “inheritance” means reference-based access to a parent class from a derived class. “Shadowing” means identifier matching to the nearest level upwards within the program tree. “Overriding” means priority of methods, operators and properties through inheritance for identifiers with matching signature. “Implementing” means copying functinalities from an interface-template.

In VB.NET and C# there are some restrictions what you can and can’t declare within each type of entity. The basic concept is that all code is written inside a class. The only exception would be the root context which itself behaves like a class. However, root level should have the main object created as soon as possible so the program can be redirected to true class-based execution. Classes can have methods (functions), operators (kind-of functions, but executed as operator instead of value), properties (a public attribute with functional purpose) and even inner classes. In addition, there can be structures (similar to classes), enums, constants, and attributes (variables). I’ll describe some restrictions that were mentioned in the MSDN documentation, but were never explained or justified why you can’t do these things. I had to figure these out myself, and there might still be some caps behind my logic. However, trying to understand the problem by oneself tends to be quite an enriching and valuable experience.

A function cannot be declared within the Block or Method context
A Block context does not have an identifying name that you could use to access it by using the dot notation. This itself is logically wrong. In addition, the member access operator (dot) only works with references, and neither block nor function is a reference. This means that functions don’t get unique memory addresses that are visible to the programmer. Even if you had a pointer to the function, it’d be still pointing to the code entry point and not to the actual member variables. Function members can never be Public. They can’t be Protected either, because functions cannot inherit from other functions. So function members are Private which means you couldn’t access them from the outside anyways. Function variables and their memory addresses will be determined during runtime because they reside in Stack. This offset can’t be calculated at compiling time. References, in the other hand, point directly to member variable addresses so the reference is always direct and valid.

This, however, doesn’t explain why the compiler couldn’t just enforce Private functions within the Block/Method context (all identifiers are local in these context levels). Firstly, there’s the logical issue: Why on earth would anyone want to defined private functions inside other functions. It’s like restricting yourself from data you’re eligible to use anyways – for no gain. Secondly, there’s the technical issue. While I *could* allow this kind of declaration in CoolBasic (even though it’s forbidden in .NET-languages), I think that it would be better for the compiler’s sake to prevent from mixing two separate scope definitors. Private/Public/Protected are intended to define reference context accessibility, the inheritance thing. Whereas keyword Dim is meant to define identifiers within nested local scopes. There’s no equivalece to Public in Method/Block context (if there was, you’d be able to call conditional code from outside, which could potentially break the program flow integrity), as explained above.

So let’s just assume that we have a function inside a local scope (another function or a block) with no separate access modifier in the declaration. The declaration is now legal as long as there are no inheritance-related modifiers or flags. We call this inner function only from inside of the hosting scope. What’s wrong with this? Well… nothing really, besides the odd visibility and reach. Can we implement this? Probably. Should we allow this? I don’t know. It just happens that when you enter a method scope you can, in fact, declare an identically named inner function. In this case, which function does a recursive call direct to? In normal rules of shadowing, it would be the same scope of the calling code unless qualified with Me or MyBase. The problem is, these two variables always refer to a class so you can’t point to the inner function. Either you use Me.myFunc() for the outer function or just myFunc() for the inner function. Also, it matters whether you make the recursive call from inside the inner function or from outside of it. Add different function signatures and you have a nice soup of failure.

As what comes to declaring classes within functions, the same rules kind of apply. You can’t use function name as parth of the dot notation, to point to a class or nested function. Even though the issue would not be reference-based at runtime (procedures get their fixed location within ASM at compiling time). It’s about the syntax and whether or not it’s allowed to do inconsistent/logically wrong things. Function references within the source code should always contain a set of brackets – which itself satisfies the member access operator (dot) because such a token will be identified as value evaluation.

A structure or enum cannot be declared within the Block or Method context
First of all, being unable to declare structures within procedures, but still being able to do so outside (which the function could use), made no sence to be. There shouldn’t be any restrictions becasue you can declare variables normally. Only so that the new structure/enum would be visible locally within the method scope. Some rules that were explained above still apply, but I think I have come up with a better explanation. Picture this: You have a structure called “myStruct” within a class context. Then you have a method that takes a typed variable (myStruct) in as a parameter. Because the scope has now changed, you can declare another structure that has the same name within the method. When the source code gets parsed for the first time, all identifier definitions are scanned. While it wouldn’t normally matter where you have the structures defined and still being able to use them from anywhere within its scope, it just happens that variables are identifiers, too. So they get scanned in the same way. You *could* do multiple passes for the source code to scan in layers, but in OOP this can be a bit problematic and slow. So in this scenario, you can define a variable as “myStruct” before and after the inner Structure is declared. Which means we have two different types for those variables even though they were typed using the same name. Confusing, eh?

When you think about it, the answer to all these problems could be the simplest one: They don’t want you to write structural definitions (such as structures, enums, functions or classes) to a code block which has executable code part (and thus no no declaration part that is separate). The basic priciple is that everything belong to their little boxes, and only access modifiers, inheritance and shadowing rule out information hiding and reach because they work in both ways in the program hierarchy. I think there’s enough reason already to conclude this think-tank into following the rules the wise guys at Microsoft have agreed upon, and not to allow nested functions in CoolBasic V3.

Managed inheritance

One of the coolest new features of CoolBasic V3 will be classes and their inheritance. In this blog entry, I’m not going into details nor will I summary exactly what aspects belong to it in CoolBasic’s case (I’ll leave that for later), but I’d like to share some conclusions on how to perserve data integrity through inheritance.

CoolBasic will support perfect hierchical inheritance of multiple classes. As in Visual Basic .NET, there will be “Me” and “MyBase” keywords which point to the current class and the parent class the current class was derived from. By default, overloaded functions between the derived and parent classes reference primarily to “local scope”. In order to specifically call the parent class’ functions “MyBase” keyword must be used in conjunction with the member access operator, for example “MyBase.MyFunction()”.

ChaosBasic (read more at CoolBasic forums) introduced a syntax which allowed multiple inheritances when a new class is created. Parent classes were separated by commas such as: “Class OpacityCow Inherits Cow, OpacityObject”. Now the question is… where does MyBase point to? How do you access the parents’ constructors? There’s obviously a design flaw with this concept, so I decided not to implement multiple inheritances in this way. Instead, much more coherent way to approach this problem, would be to only allow one inheritance per class. If the programmer wished to link multiple classes via inheritance it’d needed to be done like a->b, b->c.

In VB.NET, C#, and Java access is resticted to the direct base class to prevent inconsistencies in an object’s state. That’s why MyBase.MyBase does not exist. Some languages, however, do give access to traversing underlying classes… i.e. “::”. I haven’t decided yet whether or not I should allow this. For those who are interested in knowing more about the pros and cons of grand parent reference, I recommend visiting

This “safety net” applies to class constructors as well; CoolBasic V3 will force you to call the parent’s constructor in the derived class’ constructor. This ensures that all constructors are called when a new instance is created which in turn will result in complete and “well-formed” class instance.

Comment parsing

A few things about source code comments worth mentioning. First of all, both singleline comments and multiline comments will still exist in V3. Comments will be written pretty much the same way they’re written in C (and the related) languages. That is, singleline comments beginning with double slashes “//”, and multiline comments introduced as block that starts with “/*” and ends with “*/”. No more remstart/remend.

For now, multiline comments are stripped already in the file reading pass, and not in the lexical phase (singleline comments are handled here, though). I thought it’d be more efficient in terms of compilation time if lines that wouldn’t be processed anyway, were ignored completely instead of going through the normal tokenization. Due to this, comment ending and starting can’t occurr within a logical line. Obviously this would be easily fixed, but it’s extra work and some code recycling – which is rarely a good thing. This means that the “/*” and “*/” must be on their respective lines alone in a similar manner to how remstart and remend currently work. It may require some time to get used to this, but as it stands now, my decision is justifiable.

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