From: jkn+nin@nicorp.co.uk   
      
   On 11/02/2026 14:59, Hans Bezemer wrote:   
   > 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:   
   >>>>>> >>>>> proposal-2025-09-11?hideDiff#reply-1614>   
   >>>>>>   
   >>>>>> 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   
      
   I wrote my Forth system in order to write an application, so yes, I have   
   programmed in Forth.   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)