An alternative approach would only require the programmer to specify the number of rebindable slots the dream should contain, with the system providing a reasonable default value. In this approach, all of the slots would contain zero. The rebinding mechanism would not loop through all the bindings, but only as far as a slots-used counter indicated. All slots containing a value of zero would be skipped over. Additional Dreams words would allow the dynamic insertion and deletion of word names from the closure list of a dream.
A problem arises here, however: what would happen if a dream reslotted itself while it was active? The unbinding mechanism would become confused and not restore the old bindings properly. The same thing could happen if some other task altered the binding slots of a dream while it was active. Note that this is not the same thing as if the behavior associated with a name is altered while the dream is active. This is a fine thing to do, and will cause no such confusion when restoring old bindings. It is necessary to realize, however, that the new binding specification will not become active until the dream is activated again, after the new binding has been specified. But when the name of a word to be closed over, not the behavior to bind such a name to, is altered, the old binding saved on the active bindings stack will get stored into the wrong memory location at unbinding time. Such a catastrophe should be avoided. The idea of run-time changes to the closed over name list of a dream is attractive, but some efficient means must be found to detect whether a dream is active before such a scheme would be very robust.
Another solution would be to keep both the old bound value and its execution token on the active bindings stack and to not look at the essence at all during the restoring of the old bindings. Although this would use twice the space on the active binding stack, it would provide a robust solution to the problem.