Forth Stuff, by Don Hopkins

forth know? if
  forth learn

Forth is a stack based threaded interpretive language, that I used to program in it a whole lot. It has two stacks, unlike most other programming languages which have one. The operand stack is separate from the return stack. Arguments are passed on the operand stack, and flow of control is kept track of on the return stack.

Forth functions are called "words", and they have a header and a body. The name of a word can be any sequence of non-space characters, so Forth language documentation always includes a spoken pronunciation for each word. Other less hieroglyphic programming languages could also benefit from this convention.

The body of a Forth word typically consists of a sequence of pointers to other Forth words. This is called "threaded code". Other words are implemented as machine language primatives. There are different kinds of Forth interpreters that thread the code in various ways, but the essential thing about Forth is that code is a list of pointers to more code, which eventually bottoms out in primatives.

Forth syntax is very weird, yet extremely simple. The Forth compiler is part of the language, that Forth programmers can easily extend to define their own programming constructs and macros. Most forth systems also include an assembler with which you can define machine language primatives. You can write programatic macros that call the assembler and Forth compiler to dynamically generate code. Some Forth systems even allow you to dynamically link and call functions in libraries written in other languages.

Forth takes the "glass box" approach to language design (as opposed to the "black box" approach): Forth is essentially very simple, but you have to keep the whole thing in your head to use it. Forth environments usually provide a good decompiler that you can use to remind yourself what something does.

Here's a position paper I wrote about Rapid Prototyping in Interactive Programming Environments, that describes some of the uses of Forth

The first Forth system I used was Cap'n Software Forth, on the Apple ][, by John Draper. The first time I met John Draper was when Mike Grant brought him over to my house, because Mike's mother was fed up with Draper, and didn't want him staying over any longer. So Mike brought him over to stay at my house, instead. He had been attending some science fiction convention, was about to go to the Galopagos Islands, always insisted on doing back exercises with everyone, got very rude in an elevator when someone lit up a cigarette, and bragged he could smoke Mike's brother Greg under the table. In case you're ever at a party, and you have some pot that he wants to smoke and you just can't get rid of him, try filling up a bowl with some tobacco and offering it to him. It's a good idea to keep some "emergency tobacco" on your person at all times whenever attending raves in the bay area. My mom got fed up too, and ended up driving him all the way to the airport to get rid of him. On the way, he offered to sell us his extra can of peanuts, but my mom suggested that he might get hungry later, and that he had better hold onto them. What tact!

I had a job programming Forth for a little company called "Computer Challenges", when I was in high school. I implemented my own Forth programming environment for the Apple ][ computer, and a graphics and animation package in 6502 assembly. Then I wrote an animated graphics demo with it, promoting Forth as a cross platform game programming language across Apple ][, C64, and BBC computers. (That was more than a few years before Java.)

I designed some video games and animated graphics that used the animation package, wrote utilities in 6502 assembly, and supported a co-worker writing educational software using my Forth system.

I ported Forth from DOS 3.3 to ProDOS, adding a real file system interface, and used it to develop numerous text editors, terminal emulators, a bulletin board, a file manager, and TypeRite, an intelligent typewriter program.

At the University of Maryland Parallel Processing Lab, I ported Z-80 FIG-Forth to the ZMob parallel processor. ZMob was "the Computer of the Future, using the Processor of the Past": 128 Z80 microprocessors in parallel!

When I started programming on Suns, I found out about Mitch Bradley's 68000 forth system, and started using that for all kinds of stuff. He developed "Forthmacs", a very rich Forth programming environment for the Sun (based on Langston and Perry's Forth-83), that was my programming environment of choice for a long time.

The command line interface was very deluxe, with emacs bindings for input and history editing, with a key to display and fill in possible completions over the Forth vocabulary. A powerful feature that let me use Forth for many things I couldn't have done otherwise, was the ability to dynamically link in compiled C code, and call the functions from Forth. So I could develop libraries in C, and test them out and drive them from Forth.

Forthmacs eventually evolved into the Open Boot Proms, the stand-alone boot monitor you get when you hit L1-A on a Sun, and now it's an IEEE standard, IEEE 1275 Open Boot Firmware. Mitch, Michael Parry and Gudrun Polak now work together at Firmworks, and continue to develop and support it! You can even listen to Mitch Bradley singing the Open Firmware Song!

The first color framebuffer I programmed was a Sun-2 with a "cgone" graphics board, with Forthmacs, of course. The only documentation I had was a gnarly header file with a magic structure that was layed out so that you could map it onto the device registers, access special fields, and the address bits would be set to the right values to do what you want. Years later I learned that John Gilmore wrote that header file. I reverse engineered it, and started programming the graphics board from Forth and reverse polish notation 60020 assembly language. I made a breshenham line routine that got its color from a texture map of my face (although I didn't know it was called a texture map), and bounced a couple points around the screen drawing lines between them like "qix", ramping the pixel values, while it did three separate randomly jostling bubble sorts in the red, green, and blue components of the colormap. It looked weird!

I made my first multithreaded programmable window manager with pie menus, by breaking open the inner loop of a C window manager (X10 "uwm"), linking it into Forthmacs, and writing code in Forth that could create and pop up menus, track the mouse, and call into and delegate events to the window manager code.

We used it to administer, time, and record statistics for the experiment we did, comparing pie menus and linear menus. At one point, I wrote code that would let you throw a window and it would bounce around the screen, by starting a Forth thread that pushed it around. You could have a whole bunch of windows boucing around the screen and frantically repainting at once! I can't believe how well it performed on a little Sun 3/160, compared to how slow and bloated computers are today.

This multitasking Forth programmable window manager forshadowed my work with NeWS, a window manager programmable in multithreaded PostScript, another stack based language. Mike Gallaher and I went to visit Sun, and I read the Red PostScript book on the plane. I met the likes of Gilmore, Gosling, Rosenthal, Densmore, and Bradley (who later hired me as a summer intern), and finally saw and promptly crashed my first NeWS server (then called SunDew).

The next summer I went to work at Sun as Mitch's summer intern, and we integrated his "C-Forth" into "CADroid" and wrote a higher level user friendly extension language for that circuit design tool in Forth.

Mitch came up with and I implemented a great way to integrate the "if/then/else" and the "for arg = 1 to n" control constructs into a simple and practical "repeat/else" syntax: "arg [ stuff to repeat arg times ][ stuff to do if arg is 0 ]". You could program macros by demonstration, walking through and recording a sequence of steps, and it would prompt you in english for arguments to commands, which you could fill in either as constants (that were recorded in the macro) or descriptive prompts for run time arguments (with which you were then re-prompted). It was pretty neat, because you could walk through the first iteration of a loop, then record an else clause without effecting the drawing, then close off the loop, and it would chunk through the freshly compiled forth code executing the rest of the arg-1 iterations really fast! All of the movement commands were relative, so they could be meaningfully recorded in macros.

Later, when we were developing the Unix version of HyperTIES (a hypermedia browser) at Ben Shneiderman's Human Computer Interaction Lab, I used Forthmacs to prototype the HyperTIES hypermedia engine. I developed a hypermedia formatter library in C, that downloaded PostScript page descriptions to NeWS. To test it, I linked the library into Forthmacs. In Forth, I defined a sealed vocabulary of formatting commands that interfaced to the library, then defined the Forth "unknown word" handler to send the word to the formatter.

So we could write a web of HyperTIES pages in this new markup language, which would run through the Forth interpreter in the sealed vocabulary, which called into the C library linked into Forth, that downloaded PostScript to NeWS.

The PostScript code, running in the NeWS window system's interpreter, displayed formatted text, graphics, and interactive user interface components. Graphical "embedded menus" (now called "image maps") gave interactive feedback when you moved the mouse over them, by popping up a cut out magnified image with a drop shadow. You could click on the background and all the targets would pop up at once! You could click once on a link to get a definition (since every node had a short descriptive definition), and double click to follow the link.

The interactive front-end running in the NeWS server could send HyperTIES commands back to the formatter engine, in response to user input, to display definitions, follow links, run programs, etc. HyperTIES pages could contain formatted text, images, buttons, text editors, pie menus, font and color selectors, and other kinds of user interface components and NeWS "applets" written in PostScript.

This was before the days of HTML. I suggested that we consider using SGML as our markup language, but instead we decided to go the route of designing our own language. We required constructs that SGML did not support, like macros, if statements, and environment variables. The HyperTIES markup language allowed you to describe conditional text, adaptive documents, parameterized templates, etc.

Then I wrote an authoring tool in "MockLisp" using UniPress Emacs, that drove the hypermedia engine around as a sub-process, and let you navigate and edit the source content as text. I needed hash tables, but the closest thing Emacs had to them were "abbrevs" -- abbreviation tables. So in order to implement each master index, that mapped between identifiers and files, I had to make a buffer with a local abbrev table, and the text of the master index so I could do the reverse lookup using text search.

By now you unix haters may be grasping for your barf bag, but back in those days, I was a unix weenie, and we just did stuff like that to gross each other out, kind of like kids turn their eyelids inside out and pick their noses at each other in the lunch room. But at least it was never installed in an air traffic control, weapons command, or life support situation! Think of all those mission critical NetScape Nagivators out there, just waiting for the right moment to explode!