Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Re: Nuke separate CONTEXT and CURRENT
Message-ID: <9003290449.AA13492@jade.berkeley.edu>
Date: 29 Mar 90 00:42:27 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb@MITCH.ENG.SUN.COM
Organization: The Internet
Lines: 83

> > MB: I have recently begun to think that the notion of separate search
> > (CONTEXT) and compilation (CURRENT) vocabularies is bogus.
>
> TA: I don't see what the problem is here. The CURRENT vocabulary does not
> have anything to do dictionary searches, but just what vocabulary new
> definitions go in.

The problem is that there are 2 bits of global state to keep track of,
and 99% of the time, you want the CONTEXT and CURRENT vocabularies to
be the same anyway.  Looking through my code, the word DEFINITIONS
appears at the end of nearly every line which modifies the search order.

> My personal preference is a vocabuary stack.

ALSO/ONLY/PREVIOUS is a stack with the PUSH/POP operations factored
strangely (presumabley for historical compatibility).

 <vocabulary-name> --> POP PUSH
 ALSO    --> DUP  (= POP PUSH PUSH)
 PREVIOUS   --> POP

> But even in STOIC, DEFINITIONS would make the current vocabulary be the
> vocabulary on top of the vocabulary stack.

PostScript has a vocabulary stack (the PostScript name for "vocabulary"
is "dictionary").  There is no need for a word like DEFINITIONS, since
definitions automatically go into the dictionary on the top of the stack.
It was experience with the PostScript mechanism that suggested to me
that the Forth mechanism is overly complicated.

> In my Native Code Compiler, the words which are searched in "Native Code
> Compile" state have the same names as the standard Forth words. I put these
> words in a vocabulary called COMPOPS (back in the old days of vocabulary
> trees, this vocabulary had to be "sealed"). Anyway, COMPOPS words almost
> never refer to other COMPOPS words, thus I almost never want CONTEXT=CURRENT.
> A typical COMPOPS word (from memory):
>
> COMPOPS DEFINITIONS
>
> : 1+  \ native code compile time definition of 1+
>  FORTH \ make context FORTH again.

But note that you had to explicitly execute FORTH after defining the
new word anyway.  If CONTEXT and CURRENT were the same, your example
would be even simpler, because DEFINITIONS would not be needed:

 COMPOPS
 : 1+  \ native code compile time definition of 1+
       FORTH \ make context FORTH again.

(Actually, neither of these is strictly correct in Forth 83, because
vocabulary names are not immediate, as they are in Forth 79.  The correct
usage is [ FORTH ] ).

> >How about historical arguments?
>
> Sure. This is the way it has always been done.

I was hoping to hear some reasons why it was done this way, like perhaps
along the lines of, "In so-and-so system with vocabulary trees, you could
not solve so-and-so problem unless CONTEXT and CURRENT were separate".
Can anybody fill in those "so-and-so" blanks?


> I'm happy with the status quo.

Unfortunately, the status quo is that there are n different styles of
vocabulary creation and search order specification.  Offhand, I can
think of the following important systems, each with different handling
of vocabularies and search order:

 FIG/Forth 79  (vocabulary trees)
 Forth 83  (ALSO/ONLY, 2 flavors of SEAL)
 LMI   (VOCABULARY takes a numeric argument (I think))
 Creative Solutions (VOCABULARY takes a numeric argument)
 Forth, Inc.  (The CONTEXT variable contains several
     encoded vocabulary tokens)

All of these vocabulary schemes have problems of one sort or another.

Sigh.

Mitch