From: the.beez.speaks@gmail.com   
      
   On 16-04-2025 23:26, Anton Ertl wrote:   
   > Hans Bezemer  writes:   
   >> You can tune the behavior of most C compilers as well - comply to a   
   >> certain standard. Don't tell me you can't do that with Forth (because   
   >> you can).   
   >   
   > C standards avoid incompatible changes as good as they can.  However,   
   > because C is a keyword-based language and redefining existing names   
   > produces an error in C, even adding a single keyword or a single name   
   > can break compatibility with an existing program, and the compilers   
   > allow you to dial the specific standard in order to deal with that.   
   >   
   > Forth is better suited to deal with such changes, but then some people   
   > come along and use the misfeatures of C as encouragement for their   
   > desire to break existing programs.   
   >   
   > OTOH, Forth is worse suited to deal with dial-your-language-version   
   > options: C uses separate compilation, so if the main program uses some   
   > version of the standard, and a library uses a different version,   
   > that's typically no problem, because they are both compiled with   
   > different compiler calls (which may have different options).   
   >   
   > Forth, OTOH, compiles all the sources in one compilation run, and any   
   > choices you dial at one point tend to affect all the rest of the   
   > compilation, even if it compiles some independently developed library.   
   > One could dream up ways to deal with that problem, but given past   
   > experience, I doubt such ideas would find enough support; some would   
   > call that "WIBNI"s, while others would point out that Chuck Moore did   
   > not bring these ideas down from the mountain.   
   >   
   > - anton   
      
   I don't think so. Using K&R prototypes is significantly different from   
   ANSI prototypes. That must have broken quite some code - unless specific   
   measures were taken to allow "old format" codes as well. restrict,   
   nullptr, inline, bool - the list of added keywords is endless. BTW, so   
   is the list of deprecated keywords, like "_Bool" with was replaced by   
   the far less ugly "bool" in 2023.   
      
   So I don't think they "avoid incompatible changes".   
      
   And I don't think the argument that "Forth compiles in one go" holds up   
   as an argument to avoid cleaning up historical clutter. The different   
   versions of a "keyword" could be created as their names, followed by a   
   postfix of the standard, e.g. DO_79, DO_82, DO_94. Let's call 'em   
   "version words".   
      
   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;   
   - Assigning the proper "version" words to trampolines or DEFERs.   
      
   But I think maybe, just maybe the same effect could be achieved by using   
   wordsets. I don't know. Never implemented them. Never used them (except   
   when switching to the EDITOR wordset on the ZX Spectrum).   
      
   Now - it may be that some techniques (like hiding or unhiding words, or   
   trampolines) are not part of Forth. Well, with an overhaul you could   
   include those. And package the entire thing in a wordset, so it's optional.   
      
   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]   
   ...   
      
   That's much like setting the radix. So - why couldn't this work?   
      
   Hans Bezemer   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)