Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!pacbell.com!ucsd!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: CFAs as identifiers and Aliases
Message-ID: <9012061457.AA20059@ucbvax.Berkeley.EDU>
Date: 5 Dec 90 23:48:04 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 88

> > 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


Brought to you by Super Global Mega Corp .com