[continued from previous message]   
      
      additional word, and the people who argue 1) would also dislike the   
      proposal.   
      
   The bottom line is that the proposal would probably not find a   
   consensus and would not be accepted by the committee.  The bottom line   
   is:   
      
   >> One could dream up ways to deal with that problem, but given past   
   >> experience, I doubt such ideas would find enough support   
      
   And the bottom line of that is that proposals for incompatible changes   
   have little chance of being accepted.   
      
   >There could be special words like [FORTH78], [ANSFORTH] - which would no   
   >nothing but:   
   >- Either hiding words in the dictionary that should be disabled;   
   >- Activating words that are part of this standard;   
      
   Interestingly, Forth-79 includes a word 79-STANDARD, and Forth-83   
   includes a word FORTH-83, but Forth-94 and Forth-2012 do not include   
   such words.  We had a discussion whether we should have Forth-94 and   
   Forth-2012 versions of environmental queries for wordsets in   
   Forth-2012, but the committee decided against that.   
      
   In any case, if you want to support including libraries written for a   
   different standard, the effect of such words should be limited to a   
   specific file.  If the standards are incompatible and you want   
   libraries, and you do not provide this kind of dialing, you can take a   
   look at the Python 3 transition pain (or worse, what happened with   
   Perl6) to see what happens.  The Python community has learned from   
   that experience not to introduce such incompatible changes again.   
      
   >- Assigning the proper "version" words to trampolines or DEFERs.   
      
   That's exactly the wrong thing to do.  You want to statically bind the   
   name to the word with the right version.  E.g. if you have a Forth-83 program   
      
     forth-83   
     100 load ( includes a library written in Forth-79)   
      
     : foo ( ... -- ... )   
       ... not ... ;   
      
   and the library contains   
      
     79-standard   
     : bar ( ... -- ... )   
       ... not ... ;   
      
   you want the use of NOT in FOO to be statically bound to (what   
   Forth-94 calls) INVERT and the NOT in BAR to be statically bound to   
   0=; you usually don't want BAR or FOO to change its behaviour   
   depending on which standard is selected.   
      
   >But I think maybe, just maybe the same effect could be achieved by using   
   >wordsets.   
      
   I assume you mean wordlists.  Yes, the effect of switching between the   
   Forth-83 NOT and the Forth-79 NOT can be achieved by having a wordlist   
   containing the Forth-79 words and a wordlist containing the Forth-83   
   words, and putting it in the search order.   
      
   >So, if we compile an external library using a mix of Forth-79, ANS Forth   
   >and Forth 2012, it could be as simple as:   
   >   
   >INCLUDE a.fs   
   >INCLUDE b.fs   
   >[FORTH2012]   
   >   
   >a.fs:   
   >[FORTH79]   
   >...   
   >   
   >b.fs:   
   >[ANSFORTH]   
   >...   
      
   There is 79-STANDARD, but there is no word equivalent to [FORTH2012]   
   or [ANSFORTH].  So a program that contains "[FORTH2012]" without first   
   defining it is not Forth-2012-compliant.  And a program that contains   
   [ANSFORTH] without first defining it is not Forth-94 compliant.   
      
   >That's much like setting the radix.   
      
   BASE is one of the misfeatures of Forth, and demonstrates the   
   disadvantage of having a state for the rest of the text   
   interpretation, and the Chuck Moore approach to .  Do you start every   
   file with DECIMAL or HEX?  Looking at SwiftForth (where one might   
   expect the most Chuck Moore influence), I see 26 occurences of DECIMAL   
   and 16 occurences of HEX, and usually not before the first occurence   
   of an integer with several digits.  As an example, the file that   
   contains the definition   
      
   : DECIMAL ( -- )   10 BASE ! ;   
      
   does not contain an invocation of DECIMAL before this use of "10".   
      
   >So - why couldn't this work?   
      
   As mentioned, there is no [FORTH2012] and no [ANSFORTH].   
      
   Moreover, this general approach does not work for BASE: If the next   
   standard required that systems start out in, say, octal, I am sure   
   that a lot of the existing source files would fail unless you invoked   
   DECIMAL before the INCLUDE.  BASE only works (and only so-so) because   
   every sane system defaults to DECIMAL, and that does not change   
   between standard versions.   
      
   - anton   
   --   
   M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html   
   comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html   
        New standard: https://forth-standard.org/   
   EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/   
   EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)