??Log 2: How I Created my own programming language?

Disclaimer: If you haven't read the previous newsletter, you may not fully understand this one. Click here to read!

Saksham Rapid Object Notation (SRON) is a high-level, procedural, dynamically typed, and compiled + interpreted programming language that provides an easy and expressive syntax along with exceptional speed, surpassing Java, Python, C#, JavaScript, and even C in many cases.        

In the previous newsletter, I revealed my problems and struggles and how I decided to create my own programming language. This one will explain how SRON's datatypes are implemented. So, let's start!

There are multiple design approaches for developing a compiler, such as stack-based and tree-based. However, my plan for developing SRON's compiler is different. For great simplicity, scalability, stability, and speed, I realized that these traditional compiler designs were not suitable. Instead, I created my own compiler design approach, which I named "vector-based compiler design". In this approach, the tokens are linearly stored in memory, and compilation operations are performed on them. This results in a simple design, exceptional speed, and a quick compilation process.

Initially, my plan was to make SRON solely an interpreted programming language, so I started with the implementation of datatypes. Using C++'s Object-Oriented Concepts, I first implemented the base class named 'Any'. If you have worked with SRON, you know the power of the 'Any' keyword very well. C# .NET also has a base class named 'Object', and Python has an 'object' class. These base classes help maintain consistency among all the types (classes) in these programming languages.

After that, I started implementing primitive datatypes like Int, Double, Char, Bool, String, and List, which inherit from the base class 'Any'. Various necessary methods like TYPE() and PRINT() are declared as pure virtual functions so that consistency can be achieved across all datatypes.

List is highly optimized using a vectorization technique. As I was implementing these datatypes, I was getting new ideas about methods that are required in all datatypes to make things easier.

After the implementation of datatypes was done, I needed to implement the Argument List.

The Argument List is a type of List that is specially developed and optimized for passing arguments to a function in SRON.

Languages like C and C++ use a stack data structure, whereas SRON stores arguments linearly. Even with a large number of arguments, there is no significant performance difference because the Argument List is optimized using vectorization.

It is very necessary to store variables along with their values in an interpreted environment. Here comes my idea that the variable names and their respective values will be stored in a Hash Table, which will increase the speed of insertion, deletion, and searching operations with the least time and space complexity. So, I created another type called Variable Manager. As the name suggests, it's an entity that manages the variables available in a function.

During runtime, whenever a variable is created, the Variable Manager stores the values in memory and maps or links them with the name of the variable.

All the different units like datatypes, argument list, and variable manager throw exceptions when certain conditions are met. To improve stability and make debugging easier, I created simple and well-explained exception messages with a standard format so that debugging can be made much easier and quicker than in other programming languages. Here is an example of how SRON displays Errors and Exceptions.

In 'terminal'
Exception Caught :
||>> While searching for MAIN.srb file.

    > Reason 1 : You forgot to create the "MAIN" function.
    > Reason 2 : 'MAIN.srb' is not found in the current directory.
    > Reason 3 : If you don't know, 'MAIN.srb' is the execution start point of the code.

    ||> Solution 1 : Main function is written in uppercase like this 'MAIN'.
    ||> Solution 2 : Make a function named as 'MAIN' the compile it.        

Why did I decide to make SRON a compiled + interpreted programming language? How did I realize the bytecode? How did I optimize SRON's compiler? Answers to these questions will be provided in the next article on Sunday (July 7, 2024). Stay tuned!

Thanks for reading this article. Make sure to subscribe to this newsletter for such in-depth content and knowledge about compiler engineering.