From: dxforth@gmail.com   
      
   On 12/02/2026 12:34 am, Hans Bezemer wrote:   
   > 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 would say by the time ANS-TC began its deliberations the die had already   
   been cast.   
   The 'Standard Floating Point Extension' published in 1985 by the Forth Vendors   
   Group   
   (LMI and Micromotion with input from several vendors) required input in the   
   form:   
      
     If the floating point extension word set has been overlaid onto a   
     83-Standard Forth system, a string of the following form will be   
     compiled or interpreted as a real number:   
      
                     nnnn.nnnExx   
      
     The "E" signifier is mandatory to force the conversion of a real   
     number.  The presence of numeric digits before or after the "E"   
     is not required by this specification but may be mandatory in   
     some implementations.  A "-" sign may precede both the mantissa   
     and the exponent, a leading "+" sign is also permissible on the   
     exponent. A decimal point is optional and occur anywhere in the   
     mantissa.  For example, all of the following numbers are legal:   
      
                     -.0001E5   
                     100.0E+0   
                     1000.E-15   
      
   After Forth-83 which split vendors, ANS-TC wasn't going to do anything that   
   drew the   
   ire of an existing user base.  One only has to look at the flack Forth-94   
   received   
   when a section of existing locals users didn't get what they were expecting.   
      
   > 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!)   
      
   I get it but IMO f/p isn't something one simply LOADs - even if Forth-94 sold   
   it that   
   way as a nod to minimalists.  With the exception of folks like me (and perhaps   
   you)   
   who want to be able to load a variety of f/p packs, f/p is there when one   
   boots forth.   
   What the eyes don't see, the heart doesn't grieve.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)