wmb@MITCH.ENG.SUN.COM (03/27/90)
I have recently begun to think that the notion of separate search (CONTEXT) and compilation (CURRENT) vocabularies is bogus. Back in the old days, before run-time search order specification (ALSO/ONLY), separate search and compilation vocabularies may have bought you something worthwhile, but I'm not sure just what. These days, they just make things confusing, especially considering the Forth-83 requirement that : must set CONTEXT to CURRENT . I recently implemented a mechanism that used Forth vocabularies to implement a tree-structed name space. I set it up so that when you added a vocabulary to the search order, it automatically set the compilation vocabulary too. It sure made things simpler to thing about. Can anybody think of some arguments in favor of the separation of CONTEXT and CURRENT ? I would particularly like to hear of commonly- occurring situations where the separation helps, but strange or uncommon situations might be interesting as well. How about historical arguments? I have just about convinced myself that there is no absolute need for the separation, since it is always possible to explicitly set the search order to any desired order at any time, perhaps inside brackets ( [ .. ] ). Mitch Bradley
toma@tekgvs.LABS.TEK.COM (Tom Almy) (03/28/90)
In article <9003271432.AA19673@jade.berkeley.edu> wmb@MITCH.ENG.SUN.COM writes: >I have recently begun to think that the notion of separate search >(CONTEXT) and compilation (CURRENT) vocabularies is bogus. >Back in the old days, before run-time search order specification >(ALSO/ONLY), separate search and compilation vocabularies may have >bought you something worthwhile, but I'm not sure just what. 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. CONTEXT is a problem with Forths which implement ALSO/ONLY because in these cases CONTEXT is really a list of vocabularies and not a single vocabulary. My personal preference is a vocabuary stack. The language STOIC had this (and several other excellent features that should have become part of Forth IMHO). The word > popped the vocabuarly stack. Vocabularies by convention had names ending in "<". The STOIC< vocabulary was implicitly at the bottom the vocabulary stack and could not be popped. Executing a vocabulary name pushed that vocabulary onto the stack. Vocabulary functions were "immediate" -- when you needed words from a particular vocabulary, you would simply enclose the region like so: FOO< words... > Very visually appealing! But even in STOIC, DEFINITIONS would make the current vocabulary be the vocabulary on top of the vocabulary stack. >These days, they just make things confusing, especially considering the >Forth-83 requirement that : must set CONTEXT to CURRENT . I never liked that either. (Read on in my example ) >Can anybody think of some arguments in favor of the separation of >CONTEXT and CURRENT ? I would particularly like to hear of commonly- >occurring situations where the separation helps, but strange or uncommon >situations might be interesting as well. Well, in the assembler, ASSEMBLER words typically are not built from ASSEMBLER words (that would mean that the assembler would be made of CODE words, an interesting thought (and the reality in STOIC!) 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. LIT? IF \ literal on top of stack? LIT> 1+ >LIT \ do addition at compile time ELSE \ otherwise must compile code to do addition 1ARG \ generate necessary code to put top of stack in reg TSREG ASM INC FORTH \ increment top of stack register \ TSREG is function that returns \ current top of stack register THEN ; There we go. No COMPOPS words used, but ASSEMBLER and FORTH words were used. The headers for the FORTH words which are internal to the NCC are excised before the compiler module is saved. >How about historical arguments? Sure. This is the way it has always been done. >I have just about convinced myself that there is no absolute need for the >separation, since it is always possible to explicitly set the search >order to any desired order at any time, perhaps inside brackets ( [ .. ] ). I'm happy with the status quo. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
wmb@MITCH.ENG.SUN.COM (03/29/90)
> > 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
toma@tekgvs.LABS.TEK.COM (Tom Almy) (03/30/90)
In article <9003290449.AA13492@jade.berkeley.edu> wmb@MITCH.ENG.SUN.COM writes: >I wrote: >> My personal preference is a vocabuary stack. > >ALSO/ONLY/PREVIOUS is a stack with the PUSH/POP operations factored >strangely (presumabley for historical compatibility). And *that* is why I don't like ALSO/ONLY! >> 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. If the COMPOPS vocabulary had defining words (as it happens, it doesn't) then this might not work because the colon would be the one in COMPOPS rather than the one in FORTH. On the other hand, the definition would be simpler if colon didn't do the CURRENT @ CONTEXT ! operation. Then I could say COMPOPS DEFINTIONS FORTH and have a string of definitions without having to change vocabularies at all. >(Actually, neither of these is strictly correct in Forth 83, because >vocabulary names are not immediate, as they are in Forth 79. That's what I get for a quick from-memory hack. I reality I define : FT FORTH ; IMMEDIATE and use this in the definitions. >> >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 Well CURRENT --> where to put new definitions CONTEXT --> where to look for words Two separarate, distinct functions IMHO. I've heard an explaination for the CURRENT @ CONTEXT ! deal in colon, but I forget it (I certainly didn't agree with it). >> 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: Well the 83 Standard was so wishy-washy along these lines that just about any approach would meet the standard (fig, 79, even STOIC, but not necessarily ALSO/ONLY!). You simply had to search CONTEXT first and FORTH last, and anything else was fair game. > FIG/Forth 79 (vocabulary trees) Actually the 79 standard required that vocabularies be sealed. The search order was CONTEXT then FORTH. > LMI (VOCABULARY takes a numeric argument (I think)) Nope, but vocabularies are internally sequentially numbered and effectively become part of the name field. Words are not sequentially linked but are accessed throught a large hashing table. >All of these vocabulary schemes have problems of one sort or another. How true! Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply