From: the.beez.speaks@gmail.com   
      
   On 11-02-2026 14:09, jkn wrote:   
   > On 11/02/2026 12:54, Hans Bezemer wrote:   
   >> On 10-02-2026 18:48, jkn wrote:   
   >>> On 10/02/2026 12:36, Hans Bezemer wrote:   
   >>>> 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   
   >>>   
   >>> 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.   
   >>>   
   >>>      J^n   
   >>>   
   >>   
   >> Maybe because you have no idea how this thing works.   
   >   
   >   
   > Somewhat cheeky; I have at least written a Forth myself, even it was   
   > some 35 years ago...   
   >   
   >   
      
   But have you ever programmed in Forth? I mean - every student can write   
   a Forth compiler - and many do - but in my experience appreciating the   
   elegance of the system comes with using it. Not building it.   
      
   Like appreciation of an apple pie recipe comes with eating it, not   
   baking it.   
      
   Hans Bezemer   
      
   Hans Bezemer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)