From: anton@mips.complang.tuwien.ac.at   
      
   albert@spenarnc.xs4all.nl writes:   
   >In article <2025Sep22.085631@mips.complang.tuwien.ac.at>,   
   >Anton Ertl  wrote:   
   >   
   >>>Only after the word is found, a prefix is handled differently, compare   
   >>>immediate words. Such lookup is probably even less effort.   
   >>   
   >>My understaning is that if the user types   
   >>   
   >>123456789   
   >>   
   >>into the text interpreter, your text interpreter will search for   
   >>   
   >>123456789   
   >>12345678   
   >>1234567   
   >>123456   
   >>12345   
   >>1234   
   >>123   
   >>12   
   >>1   
   >>   
   >>and fail at the first 8 attempts, and finally match the ninth, and   
   >>only then try to convert the string into a number.  By contrast, with   
   >>recognizers, every recognizer (including REC-NAME) only has to deal   
   >>with the full string, and most other recognizers have simpler and   
   >>cheaper checks than REC-NAME.   
   >   
   >No. 123456789 is looked up in the Forth wordlist, fails, then in the   
   >minimum search wordlist.   
   >   
   >'   &   ^   0   1   2   3   4   5   6   7   
   >8   9   -   +   "   FORTH   
   >   
   >1234556789 matches the prefix 1.   
      
   How so?  Linear search through the wordlist, with prefix matching?   
   That's even slower than the approach outlined above (when that   
   approach is implemented using hash tables).   
      
   And how does matching "0r" for your roman numerals work, if "0rM"   
   matches the prefix "0"?   
      
   >>>Assume we have a PREFIX $ for hex.   
   >>>Think of a unix environment, where $ is used for environment variables   
   >>>and we want 0x for hex.   
   >>>   
   >>>NAMESPACE unix  \ That is VOCABULARY with a built-in ALSO   
   >>>unix DEFINITIONS   
   >>>' $ ALIAS 0x   
   >>>   
   >>>\ Warning: is not unique.   
   >>>: $ PARSE-NAME GET-ENV POSTPONE DLITERAL ;  IMMEDIATE PREFIX   
   >>>   
   >>>...   
   >>>...   
   >>>PREVIOUS DEFINITIONS   
   >>>As soon as you kick unix out of the search order, $ is again the   
   >>>prefix for hex and 0xCD is no more recognized.   
   >>   
   >>Gforth has REC-ENV and that is active by default, and there is usually   
   >>no reason to eliminate it from the system recognizer sequence.  You   
   >>write ${HOME}.   
   >   
   >Does that invalidate the example?   
      
   It means that we can mix standard syntax for hex numbers and   
   environment variables freely, without having to shadow one with the   
   other, or kicking one to be able to use the other.   
      
   >>>P.S. GET-ENV leaves a double. Adding POSTPONE DLITERAL makes that   
   >>>$XXXX can be used in compilation mode.   
   >>   
   >>It seems that your approach embraces state-smartness.  By contrast,   
   >>one benefit of recognizers is that they make it unnecessary to use   
   >>words like S" or TO that often are implemented as state-smart words,   
   >>or require unconventional mechanisms to avoid that.   
   >   
   >No I don't. Numbers have always been state-smart, although you   
   >won't admit to it.   
      
   A state-smart 123 would behave like   
      
   : 123   
     123 state @ if postpone literal then ; immediate   
      
   By contrast, a normal 123 behaves like   
      
   : 123   
     123 ;   
      
   Here is a test   
      
   : p123 postpone 123 ; : test [ p123 ] ; test .   
      
   Let's see how it works (outputs are shown with preceding "\ "):   
      
   : 123 \ compiling   
     123 state @ if postpone literal then ; immediate   
   \ *terminal*:2:40: warning: defined literal 123 as word ok   
   : p123 postpone 123 ; : test [ p123 ] ; test .   
   \ *the terminal*:3:39: error: Control structure mismatch   
   \ : p123 postpone 123 ; : test [ p123 ] >>>;<<< test   
      
   Now with a freshly started system:   
      
   : 123 \ compiling   
     123 ;   
   \ *terminal*:2:7: warning: defined literal 123 as word ok   
   : p123 postpone 123 ; : test [ p123 ] ; test . \ 123  ok   
      
   Now with a freshly started system:   
      
   : p123 postpone 123 ; : test [ p123 ] ; test . \ 123  ok   
      
   The last example uses REC-NUM to recognize 123.  It behaves like the   
   normal (not state-smart) word 123, showing that numbers are not   
   state-smart.   
      
   You may say that in a traditional system the last test will not work,   
   because POSTPONE does not work with numbers.  That's true, but not   
   proof of any state-smartness.  It just means that we have to look at   
   the implementation to decide it.  And in the traditional   
   implementation the text interpreter decides whether to perform the   
   interpretation or compilation semantics of a number, whereas in a   
   state-smart word, these two semantics are the same (immediate), and   
   the word itself decides when it is run what to do, based on STATE.  No   
   such thing happens with numbers, so they are not state-smart, not even   
   in a traditional system.   
      
   >In my system you can't postpone numbers, so that cannot lead to   
   >problems.   
      
   That is certainly a good idea if you have made the mistake of   
   embracing state-smartness in your system, but it is another   
   disadvantage of your approach compared to recognizers.   
      
   - 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)