From: the.beez.speaks@gmail.com
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. The rules are simple:
1. If it's a word, execute it;
2. Otherwise convert it to a number;
3. Not a number? Throw an error.
That's it. Given that a word can do its own parsing - what's missing? If
there was actually missing anything, you wouldn't be able to enter
characters or strings. Given we have CHAR and S" that doesn't seem to be
the case.
FYI, this is a canonical implementation of that interpreter:
: INTERPRET ( -- )
BEGIN
BL FIND IF EXECUTE
?STACK ABORT" Stack empty"
ELSE NUMBER THEN
AGAIN ;
Begin, get the next token, if it's a command execute it, if not convert
to a number, rinse and repeat. That's it. What this proposal does is
implementing a hook in this loop in order to attach (multiple) pieces of
code in what is a small, comprehensible and elegant piece of software.
That's not good engineering in my book.
Hans Bezemer
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
