From: jkn+nin@nicorp.co.uk
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...
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
