From: the.beez.speaks@gmail.com   
      
   On 11-02-2026 01: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.   
   >   
      
   Extending the functionality of already defined words (in previous   
   wordsets) was always a weak point of ANS-94. I don't know if other   
   language standards use this, but I don't feel comfortable with   
   "redefining" or "extending" words.   
      
   BTW, S" is one of the few examples of words that are not stateless   
   (contrary to CHAR and [CHAR], ' and ['], ." and .( etc.).   
      
   They could have spared us a lot of trouble defining S( - or whatever.   
   But consistency has never been Forth's strong point, unfortunately. It's   
   always trends that are aborted half way, because the maintenance efforts   
   are getting out of hand.   
      
   This discrepancy between pragmatism and "a brave new world" becomes   
   painfully clear when reading section 12.3.7:   
      
   "If the Floating-Point word set is present in the dictionary and the   
   current base is DECIMAL, the input number-conversion algorithm shall be   
   extended to recognize floating-point numbers."   
      
   Which means you have to do an overhaul of the text interpreter. Which is   
   a HORRIBLE requirement!   
      
   And its rationale:   
      
   "A.12.3.7 Text interpreter input number conversion. The Technical   
   Committee has more than once received the suggestion that the text   
   interpreter in Standard Forth systems should treat numbers that have an   
   embedded decimal point, but no exponent, as floating-point numbers   
   rather than double cell numbers. This suggestion, although it has merit,   
   has always been voted down because it would break too much existing   
   code; many existing implementations put the full digit string on the   
   stack as a double number and use other means to inform the application   
   of the location of the decimal point."   
      
   It would have been better if such requirement had NOT existed and (as   
   ugly as it is) S" 12.34e" >FLOAT had remained the only accepted way to   
   enter an FP number - OR a word like F% or F# had been brought into   
   existence for the time being.   
      
   I still think that meddling with the text interpreter is a big no-no and   
   an invitation to disaster. Never leave to a computer that which a   
   programmer can signify as his intent. Although I'm still not dancing on   
   the table, that is at least one of the characteristics of Alberts   
   proposal (and it leaves the text interpreter largely intact!)   
      
   Hans Bezemer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)