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