Preface

This html document is a transcript of a presentation that I did for the Silicon Valley Chapter of the Forth Interest Group back in December 2000 on the history of Forth and aha, a system that I had begun working on. I was told by some old time members of the group that although they had been coming to monthly SVFIG meetings for years that my presentation helped them connect the dots and understand more deeply many things that they had not understood over the years. I hope that this transcript will help other people who have not had the benefit of attending monthly SVFIG meetings to understand the evolution of the ideas in Forth.

Jeff Fox

June 2002



12/16/00 SVFIG

a History of Forth and aha



(video)

All right, well I'd like to thank all of you for giving me the opportunity to talk about this in front of the group. it is a chance for me to practice explaining it and perhaps get some new ideas from some of you. I need to go into the history of this project a little so that you will understand what brought me to this point and what my goals and objectives were. Most of you saw the `F21 in a Mouse' demo that I did down here some time ago where I taken the 68hc05 out of an old mouse and replaced it with one of my chips (F21) then wrote a mouse driver, an event handler, a desktop, and an application, a simple crude application as a demonstration. I put it into the mouse and do demos with it from time to time. That environment let me to realize some of the limitations that I was faced with and some of the problems that I needed to solve to move that environment forward.



Figure 1. Forth time phases. Design Edit Compile Run (ICE) (ICE) Problem Ascii Interpret Execute Analysis Files/Blocks Compile Interpret Dictionary Build Compile Dictionary Search

Chuck Moore often talks about the concept of Forth having four different time spaces; the design time, the edit time, the compile time and the run time, and how each of these is more expensive. How you would like to move things from run time to compile time if you can and move things from compile time to edit time if you can and from edit time to design time if you can, rather than going the other way and waiting to do all these things in your application at run time. that was one of the things that influenced me and I came to the conclusion that I was kind of getting a little tired of the limitations of machineforth, that I had been doing this for ten years now and I was very happy with machineforth but I that there were certain limitations so I decided to spend some time in the design phase and really look at the problems. As Chuck says, solutions do not require large amounts of code they require small amounts of well thought out code. so I began to look at the problems that I was facing.

Now in this diagram (Figure 1.) I have tried to diagram the traditional view of what Forth is: the design phase, you have a problem, you analyze it, you try to figure out how you are going to deal with your problem and solve it. That involves all the problems that you have such as the complexities of hardware, the complexities of operating systems, the complexities of the Forth that you are using, and the complexity of the problem that you are trying to solve. Once you have done that you take your design and you move to the editing phase. incrementally you factor, in this phase you factor your problem into the most logical small groups so that it express the problem in the most eloquent and clear and effective way to solve that problem.

Then you move to the edit phase and you edit the code. Then from the edit phase you move to the compile phase and compile it. Sometimes in compile phase you have to go back to the edit phase and edit the code again and then compile it again and then run it. Then sometimes you have to go back to the edit phase again and then compile your code again and test it incrementally.