# Damian Walker

Personal Web Pages

# More Progress on Expressions

Friday, 23rd August 2019

With the Great Refactoring out of the way, and with setting up a github repository for the project, I've been able to make some more concrete progress. Before all of this, Tiny BASIC was at a stage where it could parse line numbers, and simple LET statements of the form "LET variable = number."

Now I've expanded on that a bit. Expressions are still limited to a single term, and each term is still a single factor. But the system now recognises variables as well as numeric constants. It also recognises a parenthesised expression as a factor too, though of course that expression can still only be a single factor. And finally, it recognises unary positive and negative signs before the factor.

I wrote the following program to test my progress so far.

```10 LET X=5
20 LET Y=X
30 LET Z=-Y
40 LET A=(6)
50 LET B=(A)
60 LET C=A*B
70 LET D=C+1```

The expected result is that lines 10-50 should be parsed successfully, and line 60 should cause an error since I haven't implemented the parsing of arithmetic operators yet. In actual fact, while line 60 does cause an error, it's also recognised as a LET statement, which shouldn't be the case when an error occurs. So my error handling needs tightening up.

At this point I've realised that it's not enough to know that the interpreter thinks it's parsed the expression successfully. I need a way of making sure that it has, especially when I start handling more complex expressions. So before I add support for the arithmetic operators, I need to divert my attention to some kind of debug output.

Killing Two Birds with One Stone

At this point, I realised that formatted output listings are a feature that I'd wanted to include (and completely forgot about when writing the manual). It would be nice to write code with REMs, optional line numbers, careless use of upper and lower case and spacing, but have a way to convert this into the more rigid format expected by other Tiny BASIC implementations.

The part of this feature that deals with expressions is exactly the same as the debug output I'd like for testing my expression parsing. So why not implement the listing output now? Parsing the source code, and re-outputting source code from the parse tree, would be a good way to see that the parsing is working. Not just for expressions, but for the statements themselves too.

So as part of implementing expression parsing, I'm going to implement listing output of the LET statement, which includes output of expressions. The other statements can wait until later, but having expression parsing and output done already will make some of those other statements much easier to implement.