From: jkn+nin@nicorp.co.uk   
      
   On 11/02/2026 12:36, Hans Bezemer wrote:   
   > On 11-02-2026 10:05, 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...   
   >>   
   >   
   > IMHO it has. PARSE allows you to parse for any delimiter. Some have   
   > PARSE-WORD that allows skipping leading delimiters. There is also a   
   > dedicated white-space parser called PARSE-NAME.   
      
   I was basing my comment from the wording of the proposal Anton linked to:   
      
   """   
   The recognizer proposal is a factorization of the central part of the   
   text interpreter.   
      
   As before the text interpreter parses a white-space-delimited string. ...   
   """   
      
   >   
   > 4tH has a word called OMIT which only skips leading delimiters without   
   > parsing anything.   
   >   
   > Hans Bezemer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)