Basic Interpreter in Ruby

Creating a programming language is not that hard. In fact, behind the veil of initial difficulty, it turns out that most programmers have written far more complex code at some point in their careers. In this article, I will guide you through the entire process of recreating the BASIC language, one of the most influential languages of all time. Altair BASIC with a few additional improvements, to be precise — the one written by Bill Gates and Paul Allen in 1975. Later known as Microsoft BASIC, it came preinstalled on most personal computers and helped millions of people take their first steps in programming. It played a key role in making personal computing accessible to the broader public, outside of universities or laboratories (and made both of them billionaires).

This is part 1 of this article. Part 2 can be found here

Warning: this is not another 5-minute article explaining only a few basic concepts and code snippets, leaving you with unfulfilled promises and disappointment. I’ll walk you through the entire process, step by step, to the point where we will cover almost all functionalities of the BASIC language — such as variables, arrays, if/else conditions, functions, comments, subroutines, and built-in methods — with some explanation of how and why these things work.

BASIC differs from modern programming languages in several ways. First, there’s the use of line numbers: the programmer must manually number each line (lines without numbers are executed immediately and are not stored in the program buffer). Numbering lines in increments of 10 is a common convention, but not required. In practice, you might increment by 5 for things like IF conditions or loops, and by 100 or even 1000 for subroutines.

Second, all variable names, keywords, and commands must be written in uppercase. You can’t use underscores or lowercase letters.

Third, the overall simplicity of the language: in this early version of BASIC, there’s no ELSE clause. An IF statement, when true, simply jumps a few lines ahead (using GOTO), effectively skipping the code that would otherwise run if the condition was false.

In our interpreter, we will implement the ELSE keyword to extend the language’s capabilities and improve compatibility with later versions of BASIC.

Most programming languages have similar core architecture. Containing few obligatory elements: lexer, parser, interpreter and data structures for keeping current state of the program. First, the interpreter sends your code, written as plain text to the lexer, which scans it character by character and line by line. Lexer splits text into the smallest meaningful chunks in the language — tokens. A token can be a numeric, a string, keyword (e.g., LET, DEF, GOTO), an identifier, or a symbol such as bracket or a plus sign. The lexer should also throw an error if it encounters an unrecognized or invalid structure in the code. In other words, the lexer is the first line of defense. Acting like a bouncer checking IDs at the door, labeling guests and rising an alarm if someone suspicious is trying to sneak in.

Then tokens are passed to the parser. Lexer breaks down raw code into individual tokens, the parser takes those tokens and tries to make sense of them as a whole. It looks at the sequence and structure, checking whether the tokens form valid expressions or statements. Think of it as a grammar checking. Just as a sentence in English needs a subject and a verb to make sense, a line of code like LET A = 5 needs to follow a specific pattern: a keyword, an identifier, an equals sign, and a value. If the tokens don’t match any known pattern, a called a grammar rule. Parser will raise a syntax error and stop everything right there. One of the most important jobs of a parser is parsing mathematical expressions. At first glance, something like 3 + 4 * 2 + 6seems simple, but your interpreter needs clear instructions on how to evaluate it correctly. Parser must respect operator precedence (eg. multiplication before addition), handle parentheses, and properly group tokens into a nested structure that reflects the actual computation order. In our case we will use recursive descent parsing, but more about it later.

The interpreter is the final stage of the entire process. It’s in charge of actually running your code, based on the grammar rules and structure provided by the parser. For a language as simple as BASIC, we can often combine the parser and the interpreter into one, executing instructions as they are parsed. Just keep in mind that in more complex languages, these are treated as separate entities.

We can start by creating a very simple REPL-alike program:

Most interpreters can run code in two modes: REPL (read-eval-print loop) or script mode. Script mode reads code saved from a given file and executes it, while REPL mode executes code on run, reading it directly from user input written on console. Just like a irb in Ruby.

Our fresh interpreter should be able to give a list of comments, read an input and returns it:

Now we should to store code in interpreter’s memory. Let’s add a new global hash buffer to store code lines as a keys and an actual code lines as a values. This approach will allow us to quickly reach any line of code (eg by using GOTO command):

Now our buffer will store numbered lines and execute immediately these without numbers. Interrupt exception prevents from script termination with CMD/CTRL + D. LIST is a build in BASIC command to display all currently stores lines of code while NEW cleans buffer:

Please remember to always clear your buffer by usingNEW command before running a new program. Forgetting to do so might lead to endless confusion.

It’s time to start build our lexer:

The scan method does two key things: it identifies the next token in the input stream (updating the global $token variable) and it advances the position pointer in the input line by consuming the characters that make up that token.

Our lexer handles the four essential token types of BASIC: numbers (with decimal support), identifiers (variables and keywords), operators, and string literals. Here and next methods current token will be passed and stored in global variable.

Classic BASIC was case-insensitive but typically rendered in uppercase. Our implementation enforces this convention by only recognizing uppercase letters in identifiers. We also support type suffixes for variables (like A$ for strings), which was a common feature in most BASIC dialects. The string handling respects quotes, allowing for spaces and special characters within strings. This tokenizer is deliberately simple, as BASIC’s syntax is relatively straightforward compared to modern languages.

Now let’s implement a simple execution engine that can run PRINT statements:

The PRINT statement parser works by scanning through tokens in the line and handling them based on their type. For string literals (enclosed in quotes), it strips the quotes and prints the raw text. It supports BASIC’s print separators: commas insert a space between outputs while semicolons join outputs without spaces. For example, PRINT "HELLO"; "WORLD" outputs the two strings directly adjacent, while PRINT "HELLO", "WORLD" inserts a space between them. A trailing semicolon (like in PRINT "No newline";) suppresses the automatic newline, allowing multiple PRINT statements to build a single line of output. The function tracks the current cursor position in $current_pos, which will be useful for more advanced formatting features we'll implement later.

The execution engine uses the tokenizer to identify statement types and dispatch them to the appropriate handler functions. This architectural pattern is common in interpreters, and it allows for modular development where we can implement one statement type at a time. The RUN command now actually executes the program by processing lines in numerical order, which is how BASIC programs traditionally flow.

The variable $current_pos tracks the horizontal cursor position during PRINT operations, enabling proper alignment for tabulation and formatted output. This is essential for features like the TAB() function, which positions text at specific column positions, and for maintaining proper spacing when using commas and semicolons as print separators.

Now we can add code to execute the program and update the main function to call run:

Important thing to notice: in BASIC lines are always interpreted in increment order, regardless of how they were written in console. That’s why in run method we sort them first.

With this implementation we can finally interpret out first command, both immediately and with RUN command, while stored in buffer:

In BASIC, all letters in variable names must be uppercase. They may also contain digits, but never as first chars. _ were not allowed, however in some cases special chars such as ! or $ were accepted. In Altair Basic max length of variable name equals 2. This is such an inconvenience for modern programs that we will omit this restriction. LET statement wasn’t mandatory and most programmers quickly stop using it. However, in order to increase readability of code, we will keep impose it anyway.

Our variables will be stored in global hash with simple name -> value key pairs. let_statement method should correctly parse it that way. For now, this method will parse only numeric values, string will retrive 0 value. More complex mechanism will be implemented in the next chapter.

update print_statement to read variables:

For variable tokens, we first check if they exist in our global $variables hash. If found, we retrieve and display the stored value, which could be a number, string, or any other data type. For numeric literals (integers or floating-point numbers), we simply print them directly.

and to test it:

Great! Now our interpreter can both holds and prints variables.

Our interpreter still lacks ability to perform any math operations. Which was (and still is) a crucial core of every solid programming language. We’re going to implement a recursive descent parser to handle arithmetic expressions with proper operator precedence. This means that expressions like 2 + 3 * 4 are evaluated correctly (eg: to 14 not 20) respecting the mathematical order of operations. BASIC supported a range of arithmetic operations including addition, subtraction, multiplication, division, and often exponentiation. Our parser handles all of these with proper nesting of parentheses.

and add COMPARISON_OPERATORS constant on top of the file, right below global variables declarations. It’s just a hash with lambdas, containing rules on how our interpreter should behave meeting one of these operators:

<> sign is an equivalent to modern day !=. Also, BASIC doesn’t have distinction between = and ==. Comparison or assignment depends on context:

Our factor function will handle quite a lot of highest precedence elements (numbers, variables, parenthesized expressions, unary operations, function calls). So we should split it into a smaller chunks:

That’s a lot of new logic. Let’s break it down:

The refined parser implements a seven-level hierarchy of operations following extended precedence rules:

The complete precedence chain (from lowest to highest) is:

1. bitwise_or() - Handles OR operations (|, OR) - lowest precedence
2. bitwise_and() - Handles AND operations (&, AND)
3. comparison() - Manages comparison operations (>, <, >=, <=, =, <>)
4. add_sub() - Handles addition and subtraction (+, -)
5. term() - Manages multiplication and division (*, /)
6. power() - Handles exponentiation (^) with right-associativity
7. factor() - Parses atomic elements (numbers, variables, parenthesized expressions, etc.)

This hierarchy ensures that expressions like A OR B AND C > D + E * F^2 are evaluated with proper precedence: exponentiation first, then multiplication, addition, comparison, logical AND, and finally logical OR.

Bitwise vs. Logical Operations

Our parser implements smart dual-mode operations for AND and OR:

This behavior allows 5 & 3 to perform bitwise operations (resulting in 1), while X AND Y performs logical operations based on truthiness. The same dual behavior applies to OR operations.

Floating-Point Division

By converting both operands to floating-point numbers with to_f, division operations like 5 / 3 correctly return 1.6666666667 instead of the integer result 1. This matches classic BASIC behavior where division always produces decimal results.

Comparison Operations Integration

comparison() function leverages our existing COMPARISON_OPERATORS constant to handle all comparison logic consistently:

This approach is returning standardized boolean results (1 for true, 0 for false)

Right-Associative Exponentiation

Exponentiation maintains mathematical convention through recursive self-calls:

This ensures expressions like 2^3^2 evaluate as 2^(3^2) = 512, not (2^3)^2 = 64.

Modular Factor Processing

The factor() function dispatches to specialized handlers based on token type:

Comprehensive Expression Evaluation Example

To illustrate the complete system, let’s trace through a simpler but comprehensive expression: A + B * C > 5 where A=2, B=3, C=4:

1. expression() calls bitwise_or()
2. bitwise_or() calls bitwise_and() (no OR operators found)
3. bitwise_and() calls comparison() (no AND operators found)
4. comparison() calls add_sub() to get the left operand of >
5. add_sub() calls term() to get A (2)
6. add_sub() sees the + operator and saves it
7. add_sub() calls term() again for the right operand
8. This term() calls power() to get B (3)
9. This term() sees the * operator and saves it
10. term() calls power() again for the right operand
11. This power() calls factor() to get C (4)
12. power() finds no ^ operator, so returns 4
13. term() computes 3 * 4 = 12 and returns this value
14. add_sub() computes 2 + 12 = 14 and returns this value
15. Back in comparison(), it sees the > operator
16. comparison() calls add_sub() for the right operand to get 5
17. comparison() evaluates 14 > 5 using the comparison function, which returns true
18. comparison() converts the boolean result to 1 (true in BASIC)
19. bitwise_and() and bitwise_or() find no operators, so return 1
20. The final result is 1 (true)

It demonstrates how the parser correctly follows the order of operations: first multiplication (B * C), then addition (A + result), and finally comparison (result > 5), while properly converting the boolean result to BASIC's numeric representation where 1 means true and 0 means false.

By breaking down expression parsing into specialized functions for each precedence level, our interpreter can evaluate arbitrarily complex formulas while respecting all the standard rules of operator precedence and associativity — a core requirement for any programming language implementation.

Let’s update last part of our let_statement method to implement new mechanic, as previously it allowed only for simple numerics to be parsed:

and change print_statement function to read and parse expressions properly:

From now on we should be able to perform arithmetic operations properly:

Still few things are missing. We cannot perform perform arithmetic operations on variables by themself:

To fix it let’s change execute function:

This enhancement allows operations on existing variables without requiring the LET keyword. We check if the line starts with a token that matches an existing variable name and contains an equals sign. If so, we treat it as a variable assignment.

It makes common operations like incrementing counters much more convenient:

To make sure everything works just as intended we can run some additional tests:

exponentiation and precedence:

bitwise and logical operations:

unary operations:

That was long and challenging section. However within less than 200 lines of code we’ve made fully working parsing engine, capable of solving complex arithmetic, logical and bitwise operations!

The GOTO statement is perhaps the most infamous BASIC command, allowing unconditional jumps to any line number. This enables looping and basic decision making, though it can lead to “spaghetti code” if used too often. The IF statement adds conditional execution, evaluating a boolean expression and only executing the subsequent command if the condition is true. Altair BASIC from 1975 didn’t have ELSE statements implemented yet. If programmer wanted to mimic it, he could use GOTO instea. Skipping certain lines of codes if condition wasn’t fulfilled:

Good news is we will include ELSE statement the same way as it worker in latter BASIC editions, such as MS BASIC. Making pain of coding like it’s 1975 completely arbitrary:)

Our implementation includes a state machine to track line execution order, with a $goto flag to indicate when normal sequential execution should be interrupted. The comparison operators (=, <, >, etc.) are implemented as a lookup table of functions for flexibility. While GOTO is now considered poor practice in modern programming, it was central to BASIC’s design.

run function maintain sequential execution until a GOTO is encountered, at which point it resets the iterator to find and continue execution from the target line. The global $goto flag acts as a signal between the statement handler and the execution loop.

goto_statement simply evaluates the expression after GOTO (which is typically a line number but could be a computed expression), sets the global line number to this value, and raises the goto flag. The run loop then handles the actual line jumping.

StopIteration in the run function plays a key role in controlling program termination. This exception is automatically raised by the line_iterator.next() call when the end of the program is reached (i.e., there are no more lines to execute), allowing for a clean exit from the main loop. Additionally, we intentionally use this exception in the future END statement to immediately halt program execution regardless of the current position.

Now let’s implement IF statement:

We’ve split if statement logic into a couple smaller functions in order to keep our code cleaner. COMPARSION_OPERATORS constant was already declared in previous section.

The eval_expr function serves as a convenient tool for evaluating the value of expressions passed as text. It takes a string (or a character array), converts it into a unified character array format, initiates the tokenization process by calling scan(), and then passes control to the expression parser hierarchy starting with expression().

This allows us to easily compute the value of any expression provided as text — for example, a condition in an IF statement or an argument for GOTO — without needing to duplicate the parser code. It acts as a central point for expression evaluation, simplifying the implementation of many BASIC statements that require the evaluation of mathematical or logical expressions.

now we can test if everything works fine:

With IF and GOTO we can even impelement a typical loop behaviour and iterate over variables, sweet! But don’t worry, proper loops will come up soon. Now let’s add ELSE statement:

To add support for ELSE statement, we need to modify if_statement function. To check if ELSE keyword is after THEN, and to execute given code in case of a false condition. To test this we can try:

So far we’ve gave our interpreter ability to print output, to declare and use variables, parse and solve complex mathematical and logical expression and to use conditional if/else statements with GOTO keyboard. Respecting rules of BASIC line numeration. That is a solid base and even at this point we are capable of running countless number of useful programs.

In the next part we will greatly expand features of this interpreter. Implementing proper loops, arrays, comments, functions, subroutines or ability to get user’s input.

Click here to read part 2 of this article

Full version of code for this article can be found here