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. Then 1 does its thing,   
   recognizes the number, and decides to leave it on the stack or   
   compile code for it. Isn't that smart? (or is it the way Forth   
   works from day one?)   
      
   >   
   >>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?   
      
   >   
   >>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.   
   In my system you can't postpone numbers, so that cannot lead to   
   problems. "AAP" is recognized but   
   POSTPONE "AAP"   
   POSTPONE 12345   
   is rejected.   
   So "AAP" is a generalised number and share the property that it   
   may be state-smart but like numbers there are no evil consequences.   
   Not by clever planning, but by sound design.   
      
   P.S. I don't intend to present or defend PREFIX as an alternative to   
   the recognizer proposals, but it is more sound than people think.   
   Also it is lean, so advantageous for vintage systems.   
      
   >   
   >- 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)