Go with the flow: basic

Now that we’ve covered the funda­men­tals, let’s try a more chal­lenging project.

As languages, though bf and jsonic were fun to write, they weren’t much fun to program with. This time, we’ll imple­ment a version of the orig­inal fun language: BASIC, whose most famous features are its line numbers and goto state­ment:

Yes, we can run this program in DrRacket. (No prizes for guessing what happens.)

(Re)intro­ducing Basic

To be fair, not everyone agrees on the “fun” part. BASIC was invented by John Kemeny in 1964. It was designed to be easy to learn (a worthy goal, consid­ering that it was competing against FORTRAN and ALGOL). To that end, BASIC was successful.

Of course, some dissented. For instance, in 1968, Edsger Dijk­stra published “Go To State­ment Consid­ered Harmful” and later said that program­mers who started out with BASIC were “mentally muti­lated beyond hope of regen­er­a­tion”.

If Dijk­stra is right, then every programmer born before 1975 is a muti­la­tion victim. In the ’70s and ’80s, home computers were becoming common—from the so-called Trash-80, to the posh Apple II, to the popular Commodore 64. These machines didn’t have much in common except that they all ran some version of BASIC. Thus, every family that had a computer, and a nerdy child older than 8, had someone in the house writing BASIC programs.

Most likely, the programs being written were games. Any respectable young nerd had both volumes of David Ahl’s BASIC Computer Games. (Yes, the books contained printed source code. This was before online networks.)

In truth, Mr. Ahl’s books didn’t teach you much about program­ming. Mostly, they taught you to become a careful typer of programs: if you tran­scribed one line incor­rectly, your game wouldn’t work. (Attempting the intri­cate Eliza program was a famously dangerous mission.) The programs them­selves usually had little in the way of comments to explain their logic. The one-letter vari­able names didn’t help either.

Still, Ahl’s books taught young nerds an impor­tant lesson: that the computer was not a closed system. Rather, it was a malleable device that could be trained to do your bidding.

Why imple­ment Basic?

Not for the games, certainly. Anyone who’s owned a game console in the last 30 years won’t be impressed by Wumpus.

But as a language design, BASIC remains inter­esting because it’s an unusual hybrid. It incor­po­rates the direct-manip­u­la­tion aspects of a low-level language (e.g., assembly languages, which frequently include a goto-like instruc­tion called jmp). But it also incor­po­rates the symbolic and func­tional aspects of a high-level language (e.g., C or Python, which frequently include a goto-like state­ment called return). Program­ming in BASIC feels appeal­ingly direct, like wiring compo­nents together on a bread­board.

As we’ve learned in previous tuto­rials, every language imple­mented in Racket is really a source-to-source compiler that converts a certain language into the equiv­a­lent Racket program.

There­fore, where possible, it’s helpful to create corre­la­tions between language features in Racket and features of our target language. BASIC vari­ables should be imple­mented as Racket vari­ables; BASIC func­tions should be imple­mented as Racket func­tions. This is imme­di­ately valu­able because it simpli­fies the imple­men­ta­tion. But it also pays divi­dends down the road, because it lets our language coop­erate better with other Racket languages and tools. For instance, we’ll even­tu­ally be able to import vari­ables & func­tions from a basic source file into an ordi­nary Racket file.

But where BASIC is different—for instance, its numbered lines, its arbi­trary goto state­ment, and other unusual program-control features—we’ll figure out how to simu­late the behavior within Racket.

Along the way, we’ll also see how to imple­ment nicer error handling within DrRacket, to make our basic programs easier to write and debug.