Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #134559 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2026-02-09 07:49 +0000 |
| Last post | 2026-03-19 23:13 +0000 |
| Articles | 20 on this page of 97 — 14 participants |
Back to article view | Back to comp.lang.forth
Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-09 07:49 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-10 13:36 +0100
Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-10 17:48 +0000
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-11 11:21 +1100
Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 09:05 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-11 12:46 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 13:36 +0100
Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 20:49 +0000
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-11 18:37 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 12:25 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 14:34 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-12 11:35 +1100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 07:24 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 10:59 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 10:13 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:22 +0100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:07 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-12 20:59 +1100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 12:35 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:30 +0100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:44 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 07:35 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 10:55 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-13 08:27 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:43 +0100
Re: Recognizer proposal Gerry Jackson <do-not-use@swldwa.uk> - 2026-02-13 23:50 +0000
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-14 12:53 +1100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-15 13:33 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-16 12:18 +1100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-19 13:42 +0100
Evolution of Forths was Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-19 14:38 +0100
Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-20 12:33 +1100
Re: Evolution of Forths was Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-20 11:58 +0100
Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-24 10:45 +1100
Re: Evolution of Forths was Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-21 16:35 +0100
Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-24 13:13 +1100
Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-02-25 20:25 -0800
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-26 06:53 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-26 13:09 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-27 20:24 +1100
Re: Recognizer proposal Gerry Jackson <do-not-use@swldwa.uk> - 2026-02-27 09:25 +0000
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-27 14:48 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-27 19:21 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-28 10:15 +1100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-28 15:34 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-28 17:56 +0100
Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-02-28 22:45 -0800
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-01 07:54 +0000
Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-01 14:17 -0800
Re: Recognizer proposal antispam@fricas.org (Waldek Hebisch) - 2026-03-02 00:21 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-02 12:36 +0100
Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-04 16:48 -0800
Re: Recognizer proposal antispam@fricas.org (Waldek Hebisch) - 2026-03-02 00:17 +0000
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-26 07:32 -0600
Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-02 13:23 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-03 13:47 +0100
Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-03 14:39 +0000
Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-04 16:52 -0800
Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-06 10:54 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-06 12:22 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-03-07 17:58 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-03-03 18:33 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 13:54 +0100
Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 13:09 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 15:59 +0100
Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 20:46 +0000
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-11 16:30 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 12:07 +0100
Re: Recognizer proposal Lars Brinkhoff <lars.spam@nocrew.org> - 2026-02-12 13:00 +0000
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 12:55 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 14:17 +0100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:28 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-14 01:23 +1100
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-16 22:07 -0600
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-17 21:25 +1100
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-17 08:16 -0600
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:32 +0000
Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-02-17 14:13 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-17 20:21 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-18 13:08 +1100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-11 12:29 +0100
Re: Recognizer proposal minforth <minforth@gmx.net> - 2026-02-18 11:14 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:40 +0000
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-24 02:43 -0600
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-08 18:15 -0500
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-09 07:49 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-09 10:37 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-10 07:35 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-10 12:06 +0100
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-11 09:48 -0500
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-09 16:48 -0500
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-11 09:45 -0500
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-18 12:33 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:48 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-25 14:11 +0100
Re: Recognizer proposal NN <november.nihal@gmail.com> - 2026-03-19 19:23 +0000
Re: Recognizer proposal thresh3@fastmail.com (Lev) - 2026-03-19 23:13 +0000
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-03-07 17:58 +0100 |
| Message-ID | <nnd$1769c7a8$573b6836@d844a9f8b1a51dc4> |
| In reply to | #134641 |
On 03-03-2026 15:39, Stephen Pelc wrote:
> On 3 Mar 2026 at 13:47:54 CET, "albert@spenarnc.xs4all.nl"
> <albert@spenarnc.xs4all.nl> wrote:
>
>>> We (Wodni & Pelc GmbH) have clients using a 32 bit host who depend
>>> on 128 bit integers. They have in excess of 10,000 users of their
>>> application.
>>
>> I appreciate that you will not disclose much on your clients.
>> Can you reveal what kind of applications would use 128 bit integers
>> but not more precision?
>
> The application is construction planning. Sometimes over 10 currencies are
> used. The app must allow for a total cost of well over 10 billion dollars US.
> They tried 80 bit FP, but the difference in dollars given by an 128 bit
> integer calculation (effectively a huge spreadsheet) and an 80 bit floating
> point version was 10 million dollars for capping the piles in the new Hong
> Kong airport.. There are many examples in construction of dealing with two
> quantities, one of which is large and the other small. Capping piles is one of
> these.
>
> Stephen
>
Okay, for all those poor souls whose compilers have been rejected by
huge global corporate construction conglomerates, I'm here to tell you -
there is hope for you all.
Too lazy to create my own, I've ported a quadruple word library from the
archives of Forth Dimensions. No, it's not perfect by any standard - but
it works.
If your compiler is 64-bit, this thing allows you to do basic 256-bit
arithmetic.
To give you an idea - that is enough to give every single atom in the
observable universe a unique identifier. I mean - every single atom in
your body. Every single atom of the car just passing by. Every single
atom of the plane flying over your head. Every single atom of every girl
you ever made love to. Every single atom of every place you've ever
visited in your entire miserable life. Every single atom of every star
twinkling in the night sky.
If that ain't enough to handle the books of a minute construction
company located in a tiny speck of dust floating in the eternity of
space, I don't know what will.
Hans Bezemer
P.S. Two files, the latter is a 4tH to ANS-Forth translation.
---8<---
[UNDEFINED] |q/| [IF]
[UNDEFINED] dabs [DEFINED] 4TH# * [IF] [NEEDS lib/ansdbl.4th] [THEN]
( quadruple word arithmetic q+ q- support words )
4 constant /quad
/quad array 1temp
/quad array 2temp
[DEFINED] 4TH# [IF]
: loop-- -1 /quad 1- cells ;
: cell-- cell- dup /quad cells + ;
[ELSE]
: loop-- 0 /quad 1- cells ;
: cell-- dup /quad 1- cells + ;
[THEN]
: q! ( q# addr -- )
dup /quad cells + swap do
i !
1 cells +loop ;
: q@ ( addr -- q# )
cell-- do
i @
-1 cells +loop ;
( quadruple word arithmetic q+ q- support words)
: highbit? highbit and rot ;
[DEFINED] 4TH# [IF]
: ?carry ( #1 #2 result# -- boolean )
highbit? highbit? highbit? if and else or then 0<> ;
[ELSE]
: ?carry ( #1 #2 result# -- boolean )
highbit? highbit? highbit? if and else or then 0<> 1 and ;
[THEN]
: ?borrow ( #1 # 2 result# -- boolean )
rot ?carry ;
( quadruple word arithmetic q+ q- algorithm words )
\ all operands in temp variables
: q+temp ( -- )
0 loop-- do
1temp i + @ 2dup + dup 2swap rot ?carry swap
2temp i + @ 2dup + dup 2swap rot ?carry
swap 2temp i + ! or
-1 cells +loop drop ;
\ all operands in temp variables
: q-temp ( -- )
0 loop-- do
1temp i + @ swap 2dup - dup 2swap rot ?borrow swap
2temp i + @ 2dup - dup 2swap rot ?borrow
swap 2temp i + ! or
-1 cells +loop drop ;
( quadruple word arithmetic q+ q- driving words )
: q+ ( q#1 q#2 -- q#result)
1temp q! 2temp q! q+temp 2temp q@ ;
: q- ( q#1 q#2 -- q#result)
2temp q! 1temp q! q-temp 2temp q@ ;
( quadruple word arithmetic q* q/ support words)
\ all operands in temp variables
[DEFINED] 4TH# [IF]
: q2*temp ( --)
0 loop-- do
2temp i + @ dup 0< swap 2* rot + 2temp i + !
-1 cells +loop drop ;
[ELSE]
: q2*temp ( --)
0 loop-- do
2temp i + @ dup 0< 1 and swap 2* rot + 2temp i + !
-1 cells +loop drop ;
[THEN]
\ all operands in temp variables
: q2/temp ( --)
2temp @ 0<
/quad cells 0 do
2temp i + @ dup 1 and swap 2/
lowbits and rot if highbit or then
2temp i + !
1 cells +loop drop ;
( quadruple word arithmetic q* q/ support words )
: q2* ( q# -- q# )
2temp q! q2*temp 2temp q@ ;
: q2/ ( q# -- q# )
2temp q! q2/temp 2temp q@ ;
: q< ( q#1 q#2 -- boolean )
q- >r drop drop drop r> 0< ;
: q0> ( q#1 -- boolean )
dup 0< -rot or rot or rot or 0= or 0= ;
( quadruple word arithmetic q* q/ temporary variables )
/quad array divisor
/quad array remainder
/quad array quotient
/quad array power
/quad array result
/quad array op2
( quadruple word arithmetic unsigned q/ support words )
\ all operands in temp variables
: @power ( -- )
begin
power q@ q2* power q! divisor q@ q2* divisor q!
remainder q@ divisor q@ q<
until
power q@ q2/ power q! divisor q@ q2/ divisor q! ;
\ all operands in temp variables
: @quotient ( --)
begin
remainder q@ divisor q@ q< 0= if
remainder q@ divisor q@ q- remainder q!
quotient q@ power q@ q+ quotient q!
then
power q@ q2/ power q! divisor q@ q2/ divisor q!
power q@ q0> 0=
until ;
( quadruple word arithmetic unsigned q/)
: |q/| ( |q.dividend| |q.divisor| --
|q.remainder| |q.quotient| )
divisor q! remainder q!
0 0 0 0 quotient q! 1 0 0 0 power q!
@power
@quotient
remainder q@ quotient q@ ;
( quadruple word arithmetic unsigned q*)
: |q*| ( d#1 d#2 -- q#1 )
0 0 op2 q! 0 0 0 0 0 0 result q!
cell-bits /quad * 1- 0 do
result q@ q2* result q!
q2* dup 0< if op2 q@ result q@ q+ result q! then
loop
2drop 2drop result q@ ;
( quadruple word arithmetic q* q/ support words)
: ?dsign-abs ( d#1 d#2 -- |d#1| |d#2| boolean )
>r >r >r r@ dabs r> 0< r> swap r@ swap >r dabs r> r> 0< xor ;
: ?qminus ( q# boolean -- q# )
if >r >r >r >r 0 0 0 0 r> r> r> r> q- then ;
: ?qsign-abs ( q#1 q#2 -- |q#1| |q#2| boolean )
>r >r >r >r >r i 0< r> swap dup >r ?qminus r>
r> swap r> swap r> swap r> swap >r dup 0< dup >r ?qminus
r> r> xor ;
( quadruple word arithmetic q* q/)
: q/ ( q#1 q#2 -- q#result )
?qsign-abs >r |q/|
>r >r >r >r 2drop 2drop r> r> r> r> r> ?qminus ;
: q* ( d#1 d#2 -- q#result )
?dsign-abs >r |q*| r> ?qminus ;
( quadruple word arithmetic d*/ )
: d*/ ( d#1 d#multiplier d#divisor --
d#result)
>r >r q*
r> r> dup 0< if -1 -1 else 0 0 then
q/ 2drop ;
[DEFINED] 4TH# [IF]
hide 1temp
hide 2temp
hide loop--
hide cell--
hide highbit?
hide ?carry
hide ?borrow
hide q+temp
hide q-temp
hide q2*temp
hide q2/temp
hide divisor
hide remainder
hide quotient
hide power
hide result
hide op2
hide @power
hide @quotient
[THEN]
[THEN]
\ 1TEMP
\ 2TEMP
\ These quadruple word variables aid in the elimination of much of the
return
\ stack manipulation which otherwise would be required. They temporarily
hold
\ quadruple word numbers during the calculations of Q+TEMP and Q-TEMP. Their
\ usage does prevent the algorithms from being reentrant.
\ Q! ( Q# addr -- )
\ Stores a quadruple word number at the address given. The most significant
\ word is stored at the address and the least significant word is stored at
\ the address + 3 cells.
\ Q@ ( addr -- Q# )
\ Fetches the quadruple word number from the address given. The most
\ significant word ends up on the top of stack.
\ ?CARRY ( W#1 W#2 Result -- boolean )
\ Accepts the two inputs to an addition and the result of the addition and
\ leaves a one if a carry occurred and a zero otherwise. It does this by
\ comparing the signs of the inputs and the sign of the result using the
\ following truth table:
\ W#1 0 0 0 0 1 1 1 1
\ W#2 0 0 1 1 0 0 1 1
\ Result 0 1 0 1 0 1 0 1
\ boolean 0 0 1 0 1 0 1 1
\ ?BORROW ( W#1 W#2 Result -- boolean )
\ Accepts the two Inputs to a subtraction and the result of the subtraction
\ and leaves a one if a borrow occurred and a zero otherwise. Because of the
\ identity, if A-B=C then A=B+C, ?CARRY is used to compute the borrow.
\ Q+TEMP ( -- )
\ The two inputs are passed in 1TEMP and 2TEMP. The result of the quadruple
\ word addition is left In 2TEMP.
\ Q-TEMP ( -- )
\ The two inputs are assumed to be in 1TEMP and 2TEMP. The result of the
\ quadruple word subtraction of 2TEMP from 1TEMP is left in 2TEMP.
\ Q+ ( Q#1 Q#2 -- Q#Sum )
\ Accepts two quadruple word operands on the stack and returns the result
\ of their addition on the stack.
\ Q- ( Q#1 Q#2 -- Q#differance )
\ Accepts two quadruple word operands on the stack and returns the result
\ of the subtraction of Q#2 from Q#1 on the stack.
\ Q2*TEMP ( -- )
\ The input is passed in 2TEMP. The result of it being multiplied by two is
\ left in 2TEMP.
\ Q2/TEMP ( -- )
\ The input is passed in 2TEMP. The result of it being divided by two is
left
\ in 2TEMP.
\ Q2* ( |Q#| -- |Q#| )
\ Accepts a quadruple word number on the stack and multiplies it by two.
Note
\ that since the number is an absolute value the high order bit will
always be
\ zero thus preventing overflow from occurring.
\ Q2/ ( |Q#| -- |Q#| )
\ Accepts a quadruple word number on the stack and divides it by two. Note
\ that since the number is an absolute value the high order bit can
always be
\ made a zero without consideration of a possible sign bit on the number.
\ Q< ( Q#1 Q#2 -- boolean )
\ Compares the two quadruple word operands and leaves a one if Q#1 is less
\ than Q#2 and a zero otherwise.
\ Q0> ( Q#1 -- boolean )
\ Compares the quadruple word number on the stack with zero and leaves a one
\ if it is greater than zero and a zero if the number is less than or
equal to
\ zero.
\ DIVISOR
\ REMAINDER
\ QUOTIENT
\ POWER
\ These quadruple word variables are used to store temporary intermediate
\ results during Q/. These variables aid in the elimination of much of the
\ return stack manipulation which otherwise would be required. Their usage
\ prevents the algorithms from being reentrant.
\ RESULT
\ OP2
\ These quadruple word variables are used to store temporary intermediate
\ results during Q*. These variables aid in the elimination of much of the
\ return stack manipulation which otherwise would be required. Their usage
\ prevents the algorithms from being reentrant.
\ @POWER ( -- )
\ The inputs are passed in DIVISOR, REMAINDER and POWER. This word
multiplies
\ the divisor by two until it exceeds the dividend. It then backs up one
\ multiplication.
\ @QUOTIENT ( -- )
\ The inputs are passed in DIVISOR, REMAINDER, QUOTIENT and POWER. This word
\ repetitively subtracts all lower multiples of two of the DIVISOR
\ accumulating a quotient and obtaining a remainder.
\ |Q\| ( |Q.dividend| |Q.divisor| -- |Q.remainder| |Q.quotient|)
\ Using the absolute value of the dividend and the divisor, the absolute
value
\ of quotient and remainder are computed.
\ |Q*| ( |D#1| |D#2| -- |Q.result|)
\ The absolute values of the two double word operands are multiplied giving
\ an absolute value quadruple word result. The algorithm merely looks at
each
\ bit of the first operand and for every one bit adds an appropriately
shifted
\ second operand to the accumulating result, This algorithm could be speeded
\ up in many ways. The first is by looking at the counter operand two
bits at
\ a time (suggested by Kim Harris). A second is by initially examining the
\ operands for the one with the least number of ones to use as the counter.
\ A third way is to examine the remaining counter at each iteration for
a zero
\ value and allowing the loop to terminate early.
\ ?DSIGN-ABS ( D#1 D#2 -- |D#1| |D#2| boolean )
\ This word computes the absolute value of the two double word numbers input
\ on the stack and in addition to them leaves a one if the two numbers were
\ of differing sign or a zero if the numbers were of the same sign. This
word
\ is used to calculate the sign of the result of multiplication as well as
\ taking the absolute values of the operands which the multiply algorithm
\ requires.
\ ?QMINUS ( Q# boolean -- °Jesuit )
\ If the boolean on the top of the stack is a one, the quadruple word number
\ is two's complemented. This word is used to correct the sign of the result
\ of a multiply or divide.
\ ?QSIGN-ABS ( Q#1 Q#2 -- Q#1 Q#2 boolean )
\ This word computes the absolute value of the two quadruple word numbers
\ input on the stack and in addition to them leaves a one if the two numbers
\ were of differing sign or a zero if the numbers were of the same sign.
This
\ word is used to calculate the sign of the result of division as well as
\ taking the absolute values of the operands which the divide algorithm
\ requires.
\ Q/ ( Q#dividend Q#divisor -- Q#quotient )
\ The quadruple word quotient resulting from the division of Q#1 by Q#2 is
\ left on the stack.
\ Q* ( D#1 D#2 -- Q#result )
\ The quadruple word result of the multiplication of Q#1 and Q#2 is left on
\ the stack.
\ D*/ ( D#1 D#multiplier D#divisor -- D#result )
\ This is the typical */ but with double word inputs and outputs. A full
\ quadruple word intermediate result is used.
---8<---
: ARRAY CREATE CELLS ALLOT ;
S" ADDRESS-UNIT-BITS" ENVIRONMENT? \ query environment
[IF] \ if successful
1 chars * CONSTANT CHAR-BITS \ create constant CHAR-BITS
[ELSE]
.( Warning: CHAR-BITS undefined) CR
[THEN]
S" MAX-N" ENVIRONMENT? \ query environment
[IF] \ if successful
NEGATE 1- CONSTANT (ERROR) \ create constant (ERROR)
[ELSE]
.( Warning: ) CHAR ( EMIT .( ERROR) CHAR ) EMIT .( undefined) CR
[THEN]
S" MAX-N" ENVIRONMENT? \ query environment
[IF] \ if successful
CONSTANT MAX-N \ create constant MAX-N
[ELSE]
.( Warning: MAX-N undefined) CR
[THEN]
[UNDEFINED] cell-bits [IF]
char-bits 1 cells * constant cell-bits ( bits per cell )
[THEN]
[UNDEFINED] highbit [IF]
(error) constant highbit ( highbit in cell)
[THEN]
[UNDEFINED] lowbits [IF]
max-n constant lowbits ( lowbits in cell)
[THEN]
---8<---
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-03-03 18:33 +0100 |
| Message-ID | <nnd$70df8a92$459e3765@91f68a94bc68a6db> |
| In reply to | #134639 |
On 02-03-2026 14:23, Stephen Pelc wrote: > On 26 Feb 2026 at 05:25:12 CET, "Paul Rubin" <no.email@nospam.invalid> wrote: > >> Hans Bezemer <the.beez.speaks@gmail.com> writes: >> It does seem to me that with 32-bit systems widespread, double ints have >> gotten less important. I wouldn't want the standard behaviour to >> change, but I'd probably use the nonstandard extension if it existed. >> With the extension turned on, to get the double int, you'd use 12345 0 >> or maybe something like "D# 123 45" . >> >> Double ints are maybe still useful on 8 bit systems with 16 bit cells. > > We (Wodni & Pelc GmbH) have clients using a 32 bit host who depend > on 128 bit integers. They have in excess of 10,000 users of their > application. > > Even if they converted to a 64 bit host Forth, they would still need > double numbers. > > Stephen Like I said - you can find users for any library, no matter how fringe it is - or considered to be - by other users. It took C 50 years before it found _Bitint() "essential". And like I said before - I have full fledged triple libraries. And even used them IRL. Libs are great. You can include them if needed - and leave 'em out if they don't serve a purpose in an application. I bet I could make a quad lib if I needed it. But I don't. For that reason I won't put any effort in it. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-02-11 13:54 +0100 |
| Message-ID | <nnd$379fa837$3ffa5131@754aac6b211328ed> |
| In reply to | #134562 |
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:
>>> <https://forth-standard.org/proposals/recognizer-committee-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. 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
[toc] | [prev] | [next] | [standalone]
| From | jkn <jkn+nin@nicorp.co.uk> |
|---|---|
| Date | 2026-02-11 13:09 +0000 |
| Message-ID | <mv3dbkF4u38U1@mid.individual.net> |
| In reply to | #134568 |
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:
>>>> <https://forth-standard.org/proposals/recognizer-committee-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...
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-02-11 15:59 +0100 |
| Message-ID | <nnd$65b4b0f6$3a20bb7c@a104114058553429> |
| In reply to | #134569 |
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:
>>>>> <https://forth-standard.org/proposals/recognizer-committee-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
Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | jkn <jkn+nin@nicorp.co.uk> |
|---|---|
| Date | 2026-02-11 20:46 +0000 |
| Message-ID | <mv485qF9t6hU1@mid.individual.net> |
| In reply to | #134571 |
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:
>>>>>> <https://forth-standard.org/proposals/recognizer-committee-
>>>>>> 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.
Have I fully groked "The Forth Way"? No, I indicate my position above.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-02-11 16:30 +0000 |
| Message-ID | <2026Feb11.173046@mips.complang.tuwien.ac.at> |
| In reply to | #134568 |
Hans Bezemer <the.beez.speaks@gmail.com> 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
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-02-12 12:07 +0100 |
| Message-ID | <nnd$0bd8f009$4a43768d@e4e316720ccca85b> |
| In reply to | #134572 |
On 11-02-2026 17:30, Anton Ertl wrote: > Hans Bezemer <the.beez.speaks@gmail.com> 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. Given the design errors of ANS-94, I can understand the path that has been taken. But I'm afraid we're just digging a deeper hole. Fix the errors. Yeah, that will cause a bit of pain. I know all about it, since I made errors too - and I was the one that had to go through sometimes hundreds of programs to correct them. Find them, patch them, test them. However, I was always happy I'd made that investment, because that code was no longer burdened by that technical debt. Yeah, Forth programmers are lazy (and call it pragmatism). "Let's just ignore it and invent some ugly patch to work around it. And then call it a standard." But like I said - I won't play ball. I can't. Unless I violate 4tH's architecture. Which I won't do. BTW, if you have questions about "INTERPRET", please direct them to Forth Inc. https://www.forth.com/starting-forth/11-forth-compiler-defining-words/ I won't waste my time targeting an example - but that's just me. It's like pointing out a spelling error - as if that debunks the entire argument. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2026-02-12 13:00 +0000 |
| Message-ID | <7wtsvm2k2s.fsf@junk.nocrew.org> |
| In reply to | #134583 |
Hans Bezemer wrote: > Forth would be awkward to work with when you need a thing like "S%" > every single line." I worked professionally for a year or so with a Forth that required "#" before every number. It was indeed a little awkward, but mostly in the beginning before I got used to it.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-02-12 12:55 +0000 |
| Message-ID | <2026Feb12.135521@mips.complang.tuwien.ac.at> |
| In reply to | #134583 |
Hans Bezemer <the.beez.speaks@gmail.com> writes:
>On 11-02-2026 17:30, Anton Ertl wrote:
>> Hans Bezemer <the.beez.speaks@gmail.com> writes:
>>> 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?
[reordered]
>BTW, if you have questions about "INTERPRET", please direct them to
>Forth Inc.
>https://www.forth.com/starting-forth/11-forth-compiler-defining-words/
>
>I won't waste my time targeting an example - but that's just me. It's
>like pointing out a spelling error - as if that debunks the entire argument.
It was you who claimed that it is "a canonical implementation of that
interpreter", without even giving a source.
But reading further, it becomes clear why this INTERPRET deals only
with interpretation mode: because there is another text interpreter
for compilation mode, which the book shows slightly further down, but
which you failed to show:
: ] ( -- )
BEGIN
BL FIND DUP IF
-1 = IF EXECUTE ?STACK ABORT" Stack empty"
ELSE , THEN
ELSE DROP (NUMBER) POSTPONE LITERAL THEN
AGAIN ;
Looks a bit messier already, with a triple-nested control structure.
And again, the parsing part is missing, and in addition it does not
compile double numbers correctly. It's interesting that [COMPILE] is
replaced by POSTPONE in this code, which definitely does not run on
any Forth-94 system (because BL and FIND do not work that way in
Forth-94).
Compared to (tested in the meantime, and works):
>> : 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.
>Single numbers - I get that. Forth would be awkward to work with when
>you need a thing like "S%" every single line.
And likewise, requiring F% or F# for FP or D% for doubles etc. would
make Forth awkward. That's why we recognize floats and doubles in the
text interpreter.
BTW, your F% implementation tries to cover both interpretation and
compilation modes, which you rightly criticise S" for. That's one of
the pitfalls of using parsing words.
> Note - in those days, late seventies, early
>eighties, floating point numbers were unheard of.
To counter your misconceptions, read
<https://en.wikipedia.org/wiki/Floating-point_arithmetic#History>.
Even the PDP-11, on which Forth ran, could be bought with
floating-point hardware.
>At that time, 32-bit
>numbers were unheard of.
The Manchester Baby used a 32-bit architecture in 1948. The IBM
S/360, a mainframe with 32-bit machine words came out in 1964. The
VAX, a minicomputer with 32-bit machine words came out in 1977. The
68000, a microprocessor with 32-bit machine words came out in 1980.
And these machines followed the 36-bit machines, such as the IBM 701
and Univac 1103 from 1953.
>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).
He actually replaced STATE with two text interpretation loops similar
to the ones shown above, i.e., INTERPRET for interpretation mode and ]
for compilation mode. This change probably at some point between
microForth and polyForth.
But there were still two modes, and immediate words and all the
complications they implied. And yes, they make Forth less awkward to
use. I am glad that you admit that reducing complexity is not the
be-all and end-all of Forth.
So at the bottom line it's just a question of whether the benefit is
worth the cost. You want a Forth that needs F% or F# for FP literals,
and D% for double literals, the Forth standard committees, and, for
doubles, also Chuck Moore, have decided that the benefits of
recognized numbers were worth the costs.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-02-13 14:17 +0100 |
| Message-ID | <nnd$53d682e2$1f7b30bd@22eb394b6f10c3b7> |
| In reply to | #134585 |
On 12-02-2026 13:55, Anton Ertl wrote: > Hans Bezemer <the.beez.speaks@gmail.com> writes: >> On 11-02-2026 17:30, Anton Ertl wrote: >>> Hans Bezemer <the.beez.speaks@gmail.com> writes: >>>> 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? > > [reordered] >> BTW, if you have questions about "INTERPRET", please direct them to >> Forth Inc. >> https://www.forth.com/starting-forth/11-forth-compiler-defining-words/ >> >> I won't waste my time targeting an example - but that's just me. It's >> like pointing out a spelling error - as if that debunks the entire argument. > > It was you who claimed that it is "a canonical implementation of that > interpreter", without even giving a source. > > But reading further, it becomes clear why this INTERPRET deals only > with interpretation mode: because there is another text interpreter > for compilation mode, which the book shows slightly further down, but > which you failed to show: > > : ] ( -- ) > BEGIN > BL FIND DUP IF > -1 = IF EXECUTE ?STACK ABORT" Stack empty" > ELSE , THEN > ELSE DROP (NUMBER) POSTPONE LITERAL THEN > AGAIN ; > > Looks a bit messier already, with a triple-nested control structure. > And again, the parsing part is missing, and in addition it does not > compile double numbers correctly. It's interesting that [COMPILE] is > replaced by POSTPONE in this code, which definitely does not run on > any Forth-94 system (because BL and FIND do not work that way in > Forth-94). > > Compared to (tested in the meantime, and works): > >>> : 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. > >> Single numbers - I get that. Forth would be awkward to work with when >> you need a thing like "S%" every single line. > > And likewise, requiring F% or F# for FP or D% for doubles etc. would > make Forth awkward. That's why we recognize floats and doubles in the > text interpreter. > > BTW, your F% implementation tries to cover both interpretation and > compilation modes, which you rightly criticise S" for. That's one of > the pitfalls of using parsing words. > >> Note - in those days, late seventies, early >> eighties, floating point numbers were unheard of. > > To counter your misconceptions, read > <https://en.wikipedia.org/wiki/Floating-point_arithmetic#History>. > > Even the PDP-11, on which Forth ran, could be bought with > floating-point hardware. > >> At that time, 32-bit >> numbers were unheard of. > > The Manchester Baby used a 32-bit architecture in 1948. The IBM > S/360, a mainframe with 32-bit machine words came out in 1964. The > VAX, a minicomputer with 32-bit machine words came out in 1977. The > 68000, a microprocessor with 32-bit machine words came out in 1980. > And these machines followed the 36-bit machines, such as the IBM 701 > and Univac 1103 from 1953. > >> 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). > > He actually replaced STATE with two text interpretation loops similar > to the ones shown above, i.e., INTERPRET for interpretation mode and ] > for compilation mode. This change probably at some point between > microForth and polyForth. > > But there were still two modes, and immediate words and all the > complications they implied. And yes, they make Forth less awkward to > use. I am glad that you admit that reducing complexity is not the > be-all and end-all of Forth. > > So at the bottom line it's just a question of whether the benefit is > worth the cost. You want a Forth that needs F% or F# for FP literals, > and D% for double literals, the Forth standard committees, and, for > doubles, also Chuck Moore, have decided that the benefits of > recognized numbers were worth the costs. > > - anton Anton: "And likewise, requiring F% or F# for FP or D% for doubles etc. would make Forth awkward. That's why we recognize floats and doubles in the text interpreter." Lars: "I worked professionally for a year or so with a Forth that required "#" before every number. It was indeed a little awkward, but mostly in the beginning before I got used to it." The point is - "awkward" is in the eye of the beholder. It is a "secondary quality" according to Locke - i.e. one that depends on "taste" rather than "measurement". And hence, can never be resolved in an objective way. So, it's not much of an argument. Your argument on FP is disingenuous. I'm talking about Forth, not hardware. I think that's pretty obvious. In no contemporary book on Forth, floating point is discussed. Floating point is not a part of any contemporary Forth standard. As a matter of fact, the methods and benefits of fixed point arithmetic are discussed in great length in "Starting Forth". Not a word on floating point. Worse (in your case) - fixed point calculation is actively promoted: "Certain principles which FORTH programmers adhere to religiously are considered foolhardy by the proponents of more traditional languages. One such controversy is the question of "fixed-point" versus "floating-point representation". There is also the overhead of floating all the input data and fixing all the output data, approximately equal to one floating-point addition each. When these operations are performed thousands or millions of times, the overall saving by remaining in integer form is enormous." -- Starting Forth, the philosophy of fixed point, Leo Brodie Later, in FD he actually elaborates on this method, although I agree it only became feasable to actually use in the 64-bit era. I did a video on it, and I must admit I've applied this method more often than using one of my floating point libraries. So - no, Forth-wise it only became widespread after ANS-94. And then "the committee" and "Chuck Moore". Without their arguments it's just a "Call to authority" logical fallacy. What were their arguments? Which options have they actually considered? Where is the rationale? Or was it just "we love that it looks just like C"? And frankly, if you REALLY don't like STATE and IMMEDIATE, get to work, make an implementation and write a nice paper about it - instead of incessantly whining about it. I didn't like the Forth architecture, I set down, I wrote a compiler. And every year it is more and more capable to process vanilla Forth. You won't hear me whine. I'm much too busy for that. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-02-13 13:28 +0100 |
| Message-ID | <nnd$6e0e7046$1279c733@0df8c653378ceda3> |
| In reply to | #134583 |
In article <nnd$0bd8f009$4a43768d@e4e316720ccca85b>, Hans Bezemer <the.beez.speaks@gmail.com> wrote: >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. I'm learning chinese. If a number is used as a counter a number has to be followed by a measure word. If a number is used as an ordinal is has to be preceded by 'di'. It makes things easier to understand. In my example of prime determination determination all huge numbers are h1 h2 h3333 to tell them apart from 1 2 3333. Not too awkward. > >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: I don't think it is too bad. And replacing 'S% ' by the prefix 1 2 3 4 .. is essentially the idea of a PREFIX. <SNIP> >Hans Bezemer -- The Chinese government is satisfied with its military superiority over USA. The next 5 year plan has as primary goal to advance life expectancy over 80 years, like Western Europe.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-02-14 01:23 +1100 |
| Message-ID | <698f33d9@news.ausics.net> |
| In reply to | #134591 |
On 13/02/2026 11:28 pm, albert@spenarnc.xs4all.nl wrote: > In article <nnd$0bd8f009$4a43768d@e4e316720ccca85b>, > Hans Bezemer <the.beez.speaks@gmail.com> wrote: >> 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. > > I'm learning chinese. I feel enough of a robot as it is.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-02-16 22:07 -0600 |
| Message-ID | <10n0pik$1f2ni$1@dont-email.me> |
| In reply to | #134583 |
On 2/12/26 5:07 AM, Hans Bezemer wrote: > On 11-02-2026 17:30, Anton Ertl wrote: ... > BTW, if you have questions about "INTERPRET", please direct them to > Forth Inc. https://www.forth.com/starting-forth/11-forth-compiler- > defining-words/ > A simple search on "Swift Forth recognizers" returns this https://www.forth.com/recognizers/ Make what you will about it. In my experience, for-profit companies tend to be conservative about introducing new features, especially if they think customers won't want it. Revisions to the kForth-64 code to support recognizers are in progress. -- Krishna Myneni
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-02-17 21:25 +1100 |
| Message-ID | <69944203$1@news.ausics.net> |
| In reply to | #134600 |
On 17/02/2026 3:07 pm, Krishna Myneni wrote: > On 2/12/26 5:07 AM, Hans Bezemer wrote: >> On 11-02-2026 17:30, Anton Ertl wrote: > ... >> BTW, if you have questions about "INTERPRET", please direct them to Forth Inc. https://www.forth.com/starting-forth/11-forth-compiler- defining-words/ >> > > A simple search on "Swift Forth recognizers" returns this > > https://www.forth.com/recognizers/ > > Make what you will about it. In my experience, for-profit companies tend to be conservative about introducing new features, especially if they think customers won't want it. > ... OTOH had FI been dead against it for whatever reason it's doubtful the proposal would have gotten as far as it has. Some proposals end up permanently on death row never quite reaching the chopping block. Long ago I put up a draft proposal on c.l.f for UPC >UPPER to gauge its chance of success. The response from vendors present could be summed up as 'not interested'. By now most everyone understands what's involved and lobbies privately and strategically or not at all. I say 'most' because watching the ones that don't can be quite amusing ;-)
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-02-17 08:16 -0600 |
| Message-ID | <10n1t8b$1qm0f$1@dont-email.me> |
| In reply to | #134601 |
On 2/17/26 4:25 AM, dxf wrote: > On 17/02/2026 3:07 pm, Krishna Myneni wrote: >> On 2/12/26 5:07 AM, Hans Bezemer wrote: >>> On 11-02-2026 17:30, Anton Ertl wrote: >> ... >>> BTW, if you have questions about "INTERPRET", please direct them to Forth Inc. https://www.forth.com/starting-forth/11-forth-compiler- defining-words/ >>> >> >> A simple search on "Swift Forth recognizers" returns this >> >> https://www.forth.com/recognizers/ >> >> Make what you will about it. In my experience, for-profit companies tend to be conservative about introducing new features, especially if they think customers won't want it. >> ... > > OTOH had FI been dead against it for whatever reason it's doubtful the > proposal would have gotten as far as it has. Some proposals end up > permanently on death row never quite reaching the chopping block. Long > ago I put up a draft proposal on c.l.f for UPC >UPPER to gauge its chance > of success. The response from vendors present could be summed up as 'not > interested'. By now most everyone understands what's involved and lobbies > privately and strategically or not at all. I say 'most' because watching > the ones that don't can be quite amusing ;-) > > > I'll qualify my statement about companies being conservative as mostly applicable to small companies. Obviously companies like Microsoft, Apple, and Google will simply force large scale changes on users. But smaller companies can't do that. Regarding advancing the proposal process, one has to stay with it for an extended time. The recognizer proposal is now greater than 10 years old before it is getting close to a call for votes. My IEEE fp proposal was retired by the committe, partly due to me not having time to pursue it, but I recently changed its status back to informal proposal with the intent to improve the rationale and strengthen it. -- KM
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-02-21 15:32 +0000 |
| Message-ID | <2026Feb21.163205@mips.complang.tuwien.ac.at> |
| In reply to | #134603 |
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>I'll qualify my statement about companies being conservative as mostly
>applicable to small companies. Obviously companies like Microsoft,
>Apple, and Google will simply force large scale changes on users. But
>smaller companies can't do that.
From what I read about Microsoft, they have (or had, at earlier times)
a lot of red tape in their process for applying changes to the Windows
kernel, in order to avoid breaking existing software from ISVs. They
may not be particularly concerned with little-used software by one
ISV, but they want (or wanted?) to avoid breaking widely-used software
at all costs. It's the ecosystem that keeps Windows going. Of
course, these days Microsoft seems to focus more on cloud and AI, and
they may be less interested in the Windows Ecosystem.
Apple apparently can rely on a dedicated user base that even is
willing to put up with stuff like "You are holding it wrong". So they
can be and have been much more adventurous in breaking old stuff;
their users will always find reasons to praise such behaviour.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [prev] | [next] | [standalone]
| From | Stephen Pelc <stephen@vfxforth.com> |
|---|---|
| Date | 2026-02-17 14:13 +0000 |
| Message-ID | <10n1t1e$1qn3f$1@dont-email.me> |
| In reply to | #134600 |
On 17 Feb 2026 at 05:07:48 CET, "Krishna Myneni" <krishna.myneni@ccreweb.org> wrote: > Make what you will about it. In my experience, for-profit companies tend > to be conservative about introducing new features, especially if they > think customers won't want it. > > Revisions to the kForth-64 code to support recognizers are in progress. > > -- > Krishna Myneni We are not really conservative about new features, but we are really, really conservative about breaing clients' existing code. In other words, changing how things work is much more dangerous than adding new operations. Breaking client code leads to screams and immediate angry calls and emails. We make great efforts not to break an app with over one million lines of Forth source code. We do not have access to most client code. Stephen -- Stephen Pelc, stephen@vfxforth.com Wodni & Pelc GmbH Vienna, Austria Tel: +44 (0)7803 903612, +34 649 662 974 http://www.vfxforth.com/downloads/VfxCommunity/ free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-02-17 20:21 +0100 |
| Message-ID | <nnd$1aff8f58$24afb0a9@0be79e4e4711eae9> |
| In reply to | #134602 |
In article <10n1t1e$1qn3f$1@dont-email.me>, Stephen Pelc <stephen@vfxforth.com> wrote: >On 17 Feb 2026 at 05:07:48 CET, "Krishna Myneni" <krishna.myneni@ccreweb.org> >wrote: > >> Make what you will about it. In my experience, for-profit companies tend >> to be conservative about introducing new features, especially if they >> think customers won't want it. >> >> Revisions to the kForth-64 code to support recognizers are in progress. >> >> -- >> Krishna Myneni > >We are not really conservative about new features, but we are really, really >conservative about breaing clients' existing code. In other words, changing >how things work is much more dangerous than adding new operations. > >Breaking client code leads to screams and immediate angry calls and >emails. We make great efforts not to break an app with over one million >lines of Forth source code. We do not have access to most client code. I introduced PREFIX (mini recognizers) and nobody could notice. It changed implementation of numbers, and made possible a $ prefix, and normal strings. However all previous programs kept on working. Giving out day by day updates, where a serious client is obliged to validate the whole compiler again, is a nono by my book. > >Stephen Groetjes Albert -- The Chinese government is satisfied with its military superiority over USA. The next 5 year plan has as primary goal to advance life expectancy over 80 years, like Western Europe.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-02-18 13:08 +1100 |
| Message-ID | <69951eff$1@news.ausics.net> |
| In reply to | #134602 |
On 18/02/2026 1:13 am, Stephen Pelc wrote: > On 17 Feb 2026 at 05:07:48 CET, "Krishna Myneni" <krishna.myneni@ccreweb.org> > wrote: > >> Make what you will about it. In my experience, for-profit companies tend >> to be conservative about introducing new features, especially if they >> think customers won't want it. >> >> Revisions to the kForth-64 code to support recognizers are in progress. >> >> -- >> Krishna Myneni > > We are not really conservative about new features, but we are really, really > conservative about breaing clients' existing code. In other words, changing > how things work is much more dangerous than adding new operations. > ... But surely you have broken clients' code e.g. floating-point output. Presumably it was justified as 'short-term pain for long-term gain'. Similarly Forth-94, dual-xt etc etc. AFAICS it comes down to what one personally feels to be the right thing. If the will exists, customer reaction is a matter of management.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web