From: anton@mips.complang.tuwien.ac.at   
      
   albert@spenarnc.xs4all.nl writes:   
   >In article <2026Jan5.105209@mips.complang.tuwien.ac.at>,   
   >Anton Ertl  wrote:   
   >I think that the solution is the other way around. If you have to have   
   >CONSTANT that takes a string from the stack   
      
   That would have been a good solution if it had been in Forth from the   
   beginning (but that would have required stronger string support in the   
   original Forth).  However, that has not happened, and the only   
   standardized defining words for named word take the name from the   
   input stream, with one exception: (LOCAL) (which is hardly ever used).   
   And therefore user-defined defining words also take the name from the   
   input stream.   
      
   So, given this state of things, one may wish that things were   
   different, and define (CONSTANT), (CREATE), etc. (which BTW will be   
   hated by everyone who uses ( ... ) to comment out code), and hope that   
   everybody goes along and rewrites their defining words to take a   
   string from the stack, and then also writes a parsing counterpart, or   
   alternatively, rewrites all the uses of the defining word.   
      
   Alternatively, one can think about how to make existing (parsing)   
   defining words work when we have the name as a string on the stack.   
   One solution is NEXTNAME, another one (which also works for other   
   parsing words) is EXECUTE-PARSING.   
      
   In the ~30 years since NEXTNAME was introduced, the Forth world has not   
   converted itself to using defining words that take the name from the   
   stack.  In an alternate history where Gforth would have introduced   
   (CONSTANT), (CREATE) etc. instead, I expect that the result would have   
   been the same, so NEXTNAME has been the better approach given the   
   situation has been as it has been.   
      
   >>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 ;   
      
   Please show the documentation for SAVE SET-SRC and RESTORE.  The   
   documentation for EXECUTE-PARSING is:   
      
   |'execute-parsing' ( ... addr u xt - ...  ) gforth-0.6   
   |   Make addr u the current input source, execute xt '( ... -- ... )',   
   |then restore the previous input source.   
      
   I had been thinking along the lines of word like SAVE SET-SRC and   
   RESTORE myself, but it becomes incredibly messy to specify what these   
   words do in isolation.  And if you specify them (by having them push   
   opaque system types) such that they can only be used in this combo,   
   why have this combo instead of a single word that is still easier to   
   specify?   
      
   BTW, why do you call it :CONSTANT here, not (CONSTANT) like above?   
   Did I miss something about (CONSTANT)?   
      
   >EXECUTE-PARSING is readily defined, but you will hardly ever use it:   
      
   I have used it many times.   
      
   - 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 2025 CFP: http://www.euroforth.org/ef25/cfp.html   
   EuroForth 2025 registration: https://euro.theforth.net/   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)