From: the.beez.speaks@gmail.com   
      
   On 09-02-2026 08:49, Anton Ertl wrote:   
   > A more fleshed-out version of the current recognizer proposal is   
   > online:   
   >    
   >   
   > After many years this proposal is in transition from being fluid to   
   > solid, so if you want major upheavals, I doubt that your input will be   
   > acted upon (but you might still want to give it).  OTOH, if you find   
   > any mistakes, missing parts or unclear parts, now is the time when   
   > your input will be most effective.  In either case, please report any   
   > feedback by clicking on the Reply button on the web page above.   
   >   
   > - anton   
      
      
   Although I'm not gonna honor this proposal - for architectual and   
   technical reasons - I'd like to give my opinion anyway. Because this is   
   a mistake of Forth-83 like proportions.   
      
   But let's begin at the beginning: why is is this proposal needed? What   
   should it fix?   
      
   "The classical text interpreter is inflexible: E.g., adding   
   floating-point recognizers requires hardcoding the change; several   
   systems include system-specific hooks (sometimes more than one) for   
   plugging in functionality at various places in the text interpreter."   
      
   To begin with: this is incorrect. If I define this word:   
      
   : f%   
      bl word count >float 0= abort" Bad float"   
      state @ if postpone fliteral then   
    immediate   
      
   Floating point numbers are recognized without a problem. So - the claim   
   one needs to change the interpreter is simply false.   
      
   Now what does TF have to say about "changing the interpreter"?   
      
   "Don’t write your own interpreter/compiler when you can use Forth’s.   
   Every time you see a unique interpreter, it implies that there is   
   something particularly awkward about the problem. And that is almost   
   never the case."   
      
   Which is the case here as well. You can easily extend the language   
   without changing the interpreter.   
      
   "If you write your own interpreter, the interpreter is almost certainly   
   the most   
   complex, elaborate part of your entire application. You have switched from   
   solving a problem to writing an interpreter."   
      
   It is obvious you needs LOTS of code to make this work. Simply because   
   it doesn't come with any type information. It's clear that "F%" carries   
   an implicit type. But a recognizer needs code to recognize the type it   
   is supposed to convert. You may it is trivial, but it is code   
   nontheless. Code that has to be designed, implemented, tested and   
   maintained. Such code is not required with "F%".   
      
   Or - as TF puts it - "To simplify, take advantage of what’s available."   
      
   Let's delve in a little deeper: "The difficulty of adding to the text   
   interpreter may also have led to missed opportunities: E.g., for string   
   literals the standard did not task the text interpreter with recognizing   
   them, but instead introduced S" and S\" (and their complicated   
   definition with interpretation and compilation semantics)."   
      
   This is simply not true - and a disingenuous argument at best. Let's   
   take another, related example:   
      
   : .( [char] ) parse type ; immediate   
      
   There is very little complexity here. So, the complexity is not in the   
   PARSING of this word. The complexity lies in the (temporary) allocation   
   of this word - and the lack of an interpreted version like "S(" - which   
   would virtually completely eliminate "their complicated definition with   
   interpretation and compilation semantics."   
      
   In other words, the complexity doesn't lie within the problem itself,   
   but in the atrocious design of the S" word - which had to be patched   
   later on in order to function for the FILE wordset.   
      
   Finally, in how far does this proposal fix the aforementioned problems   
   of S"? It will still have to be allocated somewhere - and I don't see   
   how it will alleviate "their complicated definition with interpretation   
   and compilation semantics." They will only get worse, because one will   
   have to add the recognition code.. Duh!   
      
   Let's finish with some TF advise: "Anticipate things-that-may-change by   
   organizing information, NOT by adding complexity. Add complexity only as   
   necessary to make the current iteration work."   
      
   It may be clear that this proposal only ADDS complexity. It doesn't   
   alleviate the problem AT ALL. It makes it worse. Much worse. The only   
   thing it does is add some "syntactic sugar" to those C programmers that   
   couldn't live without locals.   
      
   Now - you wan't hear me say that there wasn't some history here. Chuck   
   should have refrained from adding double numbers to the interpreter.   
   "D%" would have been fine. And sure - I can understand a dot in a number   
   is a great self-documenting way to add "fractions" to fixed point number   
   calculations.   
      
   But from an architectural viewpoint, it is WRONG. Because it's a   
   slippery slope as complex numbers, floating point numbers (IEEE, single   
   precision, double precision - yeah, they come in different tastes) have   
   proven. Single numbers - I get that. Forth would be awkward to work with   
   when you need a thing like "S%" every single line.   
      
   But this.. This is not the way to go.   
      
   Hans Bezemer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)