In article <2026Jan5.105209@mips.complang.tuwien.ac.at>,   
   Anton Ertl  wrote:   
   >Gforth had had NEXTNAME ( c-addr u - ) since the beginning.  Its   
   >effect is that the next execution of a defining word uses c-addr u for   
   >the name and does not try to parse it from the input stream.  This is   
   >useful for creating words with names that have been created in the   
   >program.   
   >   
   >I have never liked the stateful interface of NEXTNAME: there is some   
   >global (or, at best, user) storage that contains the name, and there   
   >is also a deferred word that tells the word-creating word what to do   
   >in order to get the name of the word.   
      
   I think that the solution is the other way around. If you have to have   
   CONSTANT that takes a string from the stack, call it (CONSTANT). Lean   
   on (CREATE) that does a similar thing creating a multi purpose header   
   with a name on the stack that can later be filled in.   
      
   >   
   >A more recent (since Gforth-0.6) alternative to using NEXTNAME is to   
   >use EXECUTE-PARSING, which is somewhat cleaner (the word-creating word   
   >just parses the name, no deferred word in header-creation necessary),   
   >but has its own limitations; e.g., the name must not contain white   
   >space (whereas NEXTNAME does not have this limitation).   
      
   ciforth solution use SAVE / RESTORE   
   and SET-SRC. (instead of EXECUTE-PARSING)   
   : :CONSTANT  SAVE SET-SRC CONSTANT RESTORE ;   
      
   Usage:   12 "aap" :CONSTANT   
      
   Note that there is no new inventions here. These words are useful   
   and actually used to define the Forth kernel.   
   E.g. this is the definition of EVALUATE   
      
   : EVALUATE   
     SAVE SET-SRC 'INTERPRET CATCH RESTORE THROW   
      
      
   (SAVE is a leaner version of SAVE-INPUT but saves the information   
   of the return stack, as is the habit for all call/return sequences   
   on the planet.)   
      
   On its turn the INTERPRET is used in QUIT: the repl loop .   
      
   >   
   >And I have finally been bitten by this interface (and our   
   >implementation of this interface): For the defining word LOCALE:   
   >(which defines, unsurprisingly, a locale), I wanted to make it such   
   >that it creates the locale only if it does not exist already.  But   
   >LOCALE: is also called from a word that passes the name through   
   >NEXTNAME to LOCALE:.   
   >   
   >Unfortunately, the implementation of NEXTNAME hooks into the header   
   >creation of defining words, not into the name parsing of the defining   
   >word, so I cannot just check the name and only then call the   
   >header-creation stuff.  So instead I changed the part of the code that   
   >actually clled NEXTNAME, but that did not affect direct invocations of   
   >LOCALE:; for those I just documented the behaviour, which is more   
   >cumbersome than I like.   
   >   
   >I guess we will deal with the problem at a later stage, but it will   
   >probably require quite a bit of changes in Gforth.   
   >   
   >Anyway, the bottom line is: stateful interfaces eventually bite you.   
      
   I do not understand the issue fully. I just hope my solution is not   
   stateful.   
      
   P.S.   
   EXECUTE-PARSING is readily defined, but you will hardly ever use it:   
      
   : EXECUTE-PARSING   
      ROT ROT SAVE SET-SRC CATCH RESTORE THROW   
      
      
   >   
   >- anton   
      
   Groetjes Albert   
   --   
   The Chinese government is satisfied with its military superiority over USA.   
   The next 5 year plan has as primary goal to advance life expectancy   
   over 80 years, like Western Europe.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)