From: the.beez.speaks@gmail.com
On 11-02-2026 17:30, Anton Ertl wrote:
> Hans Bezemer writes:
>> 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.
>
> Chuck Moore apparently did not have an idea how this thing works,
> either, because he added complications like a compilation state and
> immediacy.
>
> But you are right: Both of these complications are unnecessary, we can
> simplify the text interpreter by leaving them away. We just have to
> write the Forth code using appropriate parsing words, i.e. instead of
>
> : DIGIT ( n -- n )
> DUP 9 > IF 7 + THEN [CHAR] 0 + ;
>
> one would write the code as
>
> : DIGIT ( n -- n )
> COMPILE DUP 9 LITERAL COMPILE > IF
> 7 LITERAL COMPILE + THEN
> [CHAR] 0 COMPILE + ;
>
> [Note that this COMPILE has to be a parsing word that compiles the
> following word, unlike fig-Forth's COMPILE , which relied on a text
> interpreter with a compilation state.]
>
> For a further simplification of the text interpreter, we should leave
> point 2 away and introduce S%, resulting in:
>
> : DIGIT ( n -- n )
> COMPILE DUP S% 9 LITERAL COMPILE > IF
> S% 7 LITERAL COMPILE + THEN
> [CHAR] 0 COMPILE + ;
>
> In addition, we can introduce [S%] to reduce the occurences of
> LITERAL, resulting in:
>
> : DIGIT ( n -- n )
> COMPILE DUP [S%] 9 COMPILE > IF
> [S%] 7 COMPILE + THEN
> [CHAR] 0 COMPILE + ;
>
> Admittedly, adding [S%] increases code size, but that's ok, because
> it's not in the text interpreter, right?
>
>> FYI, this is a canonical implementation of that interpreter:
>>
>> : INTERPRET ( -- )
>> BEGIN
>> BL FIND IF EXECUTE
>> ?STACK ABORT" Stack empty"
>> ELSE NUMBER THEN
>> AGAIN ;
>
> This is the canonical implementation? Where did you get that from?
>
>> Begin, get the next token,
>
> Where do I find this in this code?
>
>> if it's a command execute it, if not convert
>> to a number, rinse and repeat. That's it.
>
> How does the loop terminate? Are you using the fig-Forth X approach
> for that?
>
>> 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.
>
> Here's the current (untested) state of INTERPRET in the text
> interpreter:
>
> : interpret ( ... -- ... )
> begin
> parse-name dup while
> rec-forth state @ 2 + cells + @ execute
> repeat
> 2drop ;
>
> Note that it deals with interpretation and compilation state (that's
> why there is the "state @ 2 + cells +" sequence; immediacy is handled
> elsewhere. The checking of the various recognizers happens inside
> REC-FORTH.
>
> - anton
Single numbers - I get that. Forth would be awkward to work with when
you need a thing like "S%" every single line.
First I have to congratulate you with your textbook example of a
"Reductio ad absurdum". And I don't mean that as "committing a logical
falacy" - I do think you use it correctly.
Thank you for reusing my "Single numbers - I get that. Forth would be
awkward to work with when you need a thing like "S%" every single line."
But I don't think it's appropriate. And there we come to the central point:
Software doesn't fulfill a single requirement. It always has to fulfill
A SET OF REQUIREMENTS. And yes, often these requirements contradict each
other. "Many features" and "Small" can't be fulfilled at the same time.
Every feature requires code. "Speed" and "Checks" - same thing. Every
check requires time to execute. So - every programmer has to balance
these requirements. In this case - it's no different.
It's for that reason we don't have an "S%". It would make using Forth
unnecessarily awkward. Note - in those days, late seventies, early
eighties, floating point numbers were unheard of. At that time, 32-bit
numbers were unheard of. IIRC Forth-83 even pinned down that all
integers were 16-bit. Which made double numbers almost a necessity - and
hence I can understand extending the text interpreter to support double
numbers.
For the same reason I can understand why Chuck chose a thing like STATE
or a flag like IMMEDIATE. I suppose he could have chosen another
approach - with one single immediate word ([) to shutdown the compiler
and return to interpretation (] would already be executed anyway). Maybe
the compiler and the interpreter would be vectored words. May be the
interpreter would support macros. Who knows. Think of something clever
and build it to prove your point. I know I did.
Chuck was certainly open to other approaches, I quote: "LaFarr Stuart
took this attitude when he redesigned Forth. He didn’t like the input
buffer, so he implemented Forth without it, and discovered he didn’t
really need an input buffer. If you can improve the problem, it’s a
great situation to get into. It’s much
more fun redesigning the world than implementing it."
No, my objections are mostly related to the research Bell Labs did in
the late nineties "Does code decay?". Some of the conclusions of that
report were:
1. Accumulated Technical Debt: Constant, quick fixes or adding features
without cleaning up the architecture makes the code complex and rigid.
Ad 1. Oh, we got carloads of technical debt in Forth, because we think
of a thing, implement it half - and then abandon it. Or - we make a
lousy decision and then either have to live with it, or we have to
correct it years later. Did anyone say "Forth-83"?
2. Missing Maintenance: Unused, outdated, or undocumented code becomes
difficult to understand, leading to bugs when changes are required.
3. Increased Complexity: As software is modified, its entropy (disorder)
increases, raising the cost and time required for future updates.
Ad 3. Recognizers are a prime example of unnecessary complex code. Note
that Brad Eckerts FP library came with an "F#" word, which just worked
out of the box. No patches required.
DO..LOOP is still not fixed. Or do you actually think that ?DO..LOOP
fixes all of the problems? Sometimes I think, "maybe FOR..NEXT was a
better solution."
4. Bad, undocumented or violated architectures: All these make code more
vulnerable and harder to maintain, because of the kludges applied to
make things work.
Ad 4. IMHO recognizers are a prime example of "violated architectures".
BTW, so are local variables. Albert and Fred Behringer have proven -
with working code - that the current implementation is needlessly complex.
In short, if I have to balance the amount of code, the size of this
intervention (changing the text interpreter) and the functionality (and
other benefits) of this proposal, I think it's just a BAD ROI.
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
