From: anton@mips.complang.tuwien.ac.at   
      
   albert@spenarnc.xs4all.nl writes:   
   >In article <2025Sep22.103934@mips.complang.tuwien.ac.at>,   
   >Anton Ertl  wrote:   
   >>albert@spenarnc.xs4all.nl writes:   
   >>>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).   
   >   
   >I use a simple Forth and there linear search is acceptable for me.   
      
   That's fine for you, but some of us compile substantial programs   
   and/or use lots of lookups in wordlists at run time, and therefore   
   need dictionary search to be fast.   
      
   >>And how does matching "0r" for your roman numerals work, if "0rM"   
   >>matches the prefix "0"?   
   >   
   >Normal precedence rules for Forth. 0r is later defined so it is   
   >probed earlier.   
      
   So defining a prefix "0r" shadows all earlier-defined words starting   
   with "0r"?  One has to choose the prefixes well, but the same is true   
   for what recognizers should recognize.   
      
   >>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.   
   >   
   >You have tried to explain this to me several times, but this is the clearest.   
   >   
   >I terminate denotation words with [COMPILE] LITERAL or [COMPILE] DLITERAL.   
   >Suppose I change it to a system where INTERPRET checks whether an   
   >immediate word left something on the stack ( assuming a separate   
   >compilation check) and only in compilation mode adds a LITERAL   
   >(compiles LIT and the number).   
   >In that case denotations doesn't end with [COMPILE] LITERAL/DLITERAL.   
   >Would that be an acceptable implementation?   
      
   Given that you make it impossible to use the prefixes in a way where   
   the problems with state-smartness show up (by disallowing to tick or   
   postpone the prefixed words), even a state-smart implementation is   
   acceptable.   
      
   However, LITERAL is a standard word that a conforming implementation   
   cannot implement in a state-smart way.   
      
   : lit, postpone literal ;   
   : foo [ 1 lit, ] ;   
   foo . \ 1   
      
   (Gforth, iForth, SwiftForth64, and VFX64 process this example correctly).   
      
   >To end the controversy, maybe I have to admit I have smart numbers,   
   >but I manage to be ISO-94 compliant.   
   >   
   >"AAP"   
   > OK   
   > POSTPONE "AAP"   
   > POSTPONE "AAP" ? ciforth ERROR # 15 : CANNOT FIND WORD TO BE POSTPONED   
   >   
   >Maybe not ISO-2012 compliant.   
      
   Forth-2012 does not include recognizers, much less a string   
   recognizer.  And the result of the recent meeting is that the proposal   
   does not include a string recognizer, either (but it provides words   
   that allow one to add a string recognizer).  BTW, Forth-2012 is not an   
   ISO standard.   
      
   - 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)