The Dreams system provides a framework for a form of message passing object oriented programming. It makes use of a dynamic binding mechanism to permit the local view seen by a program to be temporarily altered. Within a dream, those words with local meaning to that dream have their execution behavior changed. When the dream finishes, the original meaning that was in effect at the dream's onset is restored.
We first discuss the application programmer's view of the Dreams system. Next we discuss the ways a systems programmer might go about implementing Dreams within a particular Forth programming system. Finally, we discuss ways to implement much of the underlying mechanism of Dreams in hardware, thereby eliminating most of the run-time overhead.
The inspiration for Dreams came from an experimental port of a Lisp Flavors package [Moo86], and then a Lisp closures package [Ric87], to Forth. After using this Forth closures package for a while, a number of significant changes were made that resulted in the current implementation of Dreams.
Dreams is currently written in LMI UR/Forth [Dun87] and UR/Forth-386 [Dun91]. Different Forth systems present different problems to the implementor of Dreams. A classical indirect threaded Forth interpreter, such as FIG-Forth [Tin89b,Rag80] and many Forth-83 [Dun85,Tin86] systems use, requires a rather difficult approach. A direct threaded Forth, such as Zimmer's F-PC [Tin89a], or Duncan's LMI UR/Forth is quite well suited to a single tasking version of Dreams. A token threaded system is an excellent choice for a multitasking implementation of Dreams. A subroutine threaded system can be a good choice for a multitasking system if access to the compiler source code is available, but this approach can be difficult if the compiler optimizes some words into in-line code instead of subroutine calls.