wmb@MITCH.ENG.SUN.COM (12/06/90)
> > In my world view, an execution token (previously > > known as a CFA) should be a number that identifies a particular word, > > and from which the system can infer everything that is necessary to > > known about that word. ... > I suppose you do not approve ALIASes... or you have a good solution? See, an > ALIAS must be a perfect clone of the original word. So, it must return the > same CFA, and you can't infer the correct name. > > If you have ALIASes, then a CFA can be returned by more than one token. As a matter of fact, I use aliases extensively. They are so important in one of my applications that, in the version of the kernel that I use for that application, I have added an alias bit in the word header, and alias substitution occurs at the lowest level, with FIND . There are 2 instances in which the resulting one-to-many CFA-to-name mapping is visible: 1) When decompiling, the decompiler sometimes displays the "wrong" name (i.e. not the same name that was used in the source, but one with the same function nonetheless). I view this as an inherent tradeoff of the use of aliases, independent of the issue about whether or not CFAs are important "word handles". If you have aliases, you can't guarantee perfect decompilation. 2) (This one is more subtle). In the system in question, vocabularies are more flexible than in traditional Forth systems. My vocabularies are opaque "objects" to which a set of "methods" may be applied. It is not necessary for all of the vocabularies in the system to be implemented using the same data structures, but each vocabulary must implement all of the methods in a way that is appropriate for its data structure. One of the vocabulary methods is "next-word". Given a word identifier and a vocabulary identifier, the "next-word" method returns the word identifier of the word following the input word in that vocabulary. The possibility of aliases makes it impractical to use the CFA as the word identifier for "next-word", because an endless loop could result if 2 aliases for the same CFA existed in the same vocabulary. Similarly, the name cannot be used as the word identifier for "next-word", because a name can appear multiple times within a vocabulary! The solution is to use some address within the header as the word identifier for "next-word" (e.g. the link field). Note that the particular address is unspecified; it is an opaque identifier, and a procedure is provided to translate that identifier to a CFA . That "address within the header" cannot serve as the "primary word identifier" (like the CFA) for other purposes, because words can be headerless, and those words would then not have an identifier. Note that neither of these objections matter within the domain of a standard system. The ability to decompile is not guaranteed or implied by ANS Forth, nor is it even remotely possible in many implementations (consider a native code system with in-line expansion and peephole optimization). Similary, there is no standard way to enumerate the words in a vocabulary. (A pity, but that is another topic.) Even without aliases, the name-to-CFA mapping is many-to-one, because of redefinitions and multiple vocabularies containing the same name. Aliases make the CFA-to-name mapping many-to-one also. Any way you look at it, you eventually have to admit that word "behaviors" (CFAs) and word names are not interchangeable. I submit that the execution and compilation "primitives" should execute/compile "behaviors" (CFAs) instead of names. Names are mutable and ambiguous, CFAs are not. Of course, with POSTPONE it is possible to compile a behavior that is not going to change later. The question is whether or not it should be possible to lookup the behavior at one time, save away the "handle" (CFA) for that behavior, and then compile it later. In other words, must name binding be done at compilation time (as with POSTPONE ), or can it be done earlier and then later compiled (as with ' foo ... COMPILE, ) Mitch Bradley, wmb@Eng.Sun.COM