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
EndClass

Class Class2
Public c1 As Class1
EndClass

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.