home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 117,880 of 117,927   
   albert@spenarnc.xs4all.nl to jkn+nin@nicorp.co.uk   
   Re: Recognizer proposal   
   11 Feb 26 12:46:17   
   
   In article ,   
   jkn   wrote:   
   >On 11/02/2026 00:21, dxf wrote:   
   >> On 11/02/2026 4:48 am, jkn wrote:   
   >>> ...   
   >>> I have no skin in this game at all - I am basically an observer of both   
   the language,   
   >>> and this newsgroup. But it seems strange to me that in a language that is   
   so   
   >>> self-describedly flexible as Forth, the operation of the inner interpreter   
   should   
   >>> not itself be open to flexibility.   
   >>   
   >> IIRC recognizers was a c.l.f invention.  Each forth, it was noted, had its   
   own way   
   >> of integrating floating-point into the system - fp being an 'optional   
   extension'   
   >> of Forth-94.  Typically integration was achieved through hooks the system   
   designer   
   >> had purposely built into system.  Forth-94 had already defined how the forth   
   >> interpreter should handle fp numbers.  Parsing words F# etc were not an   
   option.   
   >>   
   >> WIBN (wouldn't it be nice) it was argued if these hooks into the   
   interpreter could   
   >> be made portable.  It caught the imagination of sufficient users (in forth   
   there's   
   >> little distinction between user and system-designer) and the rest is   
   history.   
   >> Recognizers were sufficiently complicated prompting more justification than   
   fp (1)   
   >> in order to sell it.  It was 'a solution in search of a problem'.  From   
   that came   
   >> the idea that forth should be able to parse *anything* - however unlikely   
   or little   
   >> used.   
   >>   
   >> (1) While fp integration prompted recognizers, recognizers were never a   
   complete   
   >> solution.  Integrating fp into a system often requires more than simply   
   making the   
   >> interpreter recognize fp numbers.  System-specific hooks remain.   
   >>   
   >   
   > > From that came   
   > > the idea that forth should be able to parse *anything* - however   
   > >unlikely or little   
   > > used.   
   >   
   >I was a bit surprised that "a space delimits 'symbols'" has not been   
   >made more flexible...   
   >   
      
   PREFIX addresses the problem that holding to the dogma about space delimiters   
   present.   
      
   In ciforth   
      "   
      
   handles any situation :   
   .....  "########################## .....................   
      
   including ``  " a " '' which is a 3 letter string.   
      
   " is just a word that sits in the basic wordlist,   
   subject to regular search rules, e.g. observing wordlists search order.   
   It is found irrespective of spaces in the #.   
   The #-definition could be changed, omitted, hidden whatever.   
   It can be overwritten as usual, put in a wordlist etc.   
      
   Hiding " doesn't prevent S" to work.   
      
   Totally separate from whatever other prefixes you may define.   
      
   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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca