A dream is the dynamic instantiation of a binding environment. In the context of a dream, certain symbols, represented as Forth words, have a different meaning, or effect, than they normally would have in the usual Forth sense. In the Dreams system, the underlying Forth environment -- where all the Forth words have their usual meaning -- is called Reality. When execution occurs in a dream, certain Forth words, either system defined, or user defined, take on a meaning peculiar to that dream, and potentially different from reality.
For those words that embody data storage, such as variables, a dream provides another data storage area that is local to the dream. This permits variables to have an existence in a dream that is different from that same variable in either reality or another dream. This allows dreams to be used to provide local variables, but it goes further than that. When local variables are maintained on the stack, they are created at the beginning of a routine, and destroyed at the end. For this reason, they must be initialized each time the routine is executed. Dream based variables provide for ``instance variables''. Instance variables continue their existence between one execution and the next. For this reason, they preserve local state. Dream variables can be used to remember values from one invocation of a routine to the next.
Dream variables could be used, for instance, to keep track of the cursor position in a text output routine. The cursor position would persist from the outputting of one character to the next. In a windowed display system, each window could be represented by a separate dream. Each dream could keep track of its own window's cursor position by the same named variables, but each dream would have its own private copy of them. Because the same variable names are used, but the data that those variables represent is different in each dream, a common set of low level words that reference those variables can be shared among all the window dreams.
Unlike most other object oriented approaches, where the object is a static entity that is manipulated by sending it messages that result in the application of methods to the object, dreams are consequences of the dynamic execution of a program. They only have a completely defined meaning while they are actually executing. The static data structure that holds the information needed to maintain instance variables and the alteration of word meanings is called the essence of that dream.
Dreams execute by pondering thoughts within the understanding of the dream. There are no specifically declared methods as such. Any Forth word may be pondered as a thought in a dream; however, any Forth word may take on a locally defined meaning within the understanding of a dream. If that word embodies data storage, the dream can provide a local private data storage area for use by that word. A dream can also provide an operator overloading capability that permits a word to have a locally different meaning within the understanding of the dream. For instance, a colon definition can be locally redefined within a dream to refer to a different sequence of threaded code than what that same definition refers to in the understanding of reality.
Consider again the windowed text output package alluded to above. If such a package had to operate with a range of different display terminals, the method for addressing the cursor would most likely be different for each terminal. We could have a different dream for each type of terminal, and have that dream provide a local definition for the cursor addressing routine as well as all other terminal dependent operations. When outputting to a particular window, that window's dream could have an over-loaded word for the type of terminal on which the window was displayed. This would permit the same code to display text for all windows on all terminals in the system without that code having to make any direct reference to what type of terminal it was being used on.