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
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).-a OTOH, if you find
any mistakes, missing parts or unclear parts, now is the time when
your input will be most effective.-a 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%
-a bl word count >float 0= abort" Bad float"
-a 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"?
"DonrCOt write your own interpreter/compiler when you can use ForthrCOs. 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 whatrCOs 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.
On 11/02/2026 4:48 am, jkn wrote:
...
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.
IIRC recognizers was a c.l.f invention. Each forth, it was noted, had its own way
of integrating floating-point into the system - fp being an 'optional extension'
of Forth-94. Typically integration was achieved through hooks the system designer
had purposely built into system. Forth-94 had already defined how the forth interpreter should handle fp numbers. Parsing words F# etc were not an option.
WIBN (wouldn't it be nice) it was argued if these hooks into the interpreter could
be made portable. It caught the imagination of sufficient users (in forth there's
little distinction between user and system-designer) and the rest is history. Recognizers were sufficiently complicated prompting more justification than fp (1)
in order to sell it. It was 'a solution in search of a problem'. From that came
the idea that forth should be able to parse *anything* - however unlikely or little
used.
(1) While fp integration prompted recognizers, recognizers were never a complete
solution. Integrating fp into a system often requires more than simply making the
interpreter recognize fp numbers. System-specific hooks remain.
From that came
the idea that forth should be able to parse *anything* - however
unlikely or little
used.
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"?
"DonrCOt write your own interpreter/compiler when you can use ForthrCOs. >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."
Hans Bezemer
On 11/02/2026 00:21, dxf wrote:
On 11/02/2026 4:48 am, jkn wrote:
...
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.
IIRC recognizers was a c.l.f invention. Each forth, it was noted, had its own way
of integrating floating-point into the system - fp being an 'optional extension'
of Forth-94. Typically integration was achieved through hooks the system designer
had purposely built into system. Forth-94 had already defined how the forth >> interpreter should handle fp numbers. Parsing words F# etc were not an option.
WIBN (wouldn't it be nice) it was argued if these hooks into the interpreter could
be made portable. It caught the imagination of sufficient users (in forth there's
little distinction between user and system-designer) and the rest is history.
Recognizers were sufficiently complicated prompting more justification than fp (1)
in order to sell it. It was 'a solution in search of a problem'. From that came
the idea that forth should be able to parse *anything* - however unlikely or little
used.
(1) While fp integration prompted recognizers, recognizers were never a complete
solution. Integrating fp into a system often requires more than simply making the
interpreter recognize fp numbers. System-specific hooks remain.
From that came
the idea that forth should be able to parse *anything* - however
unlikely or little
used.
I was a bit surprised that "a space delimits 'symbols'" has not been
made more flexible...
On 11/02/2026 00:21, dxf wrote:
On 11/02/2026 4:48 am, jkn wrote:
...
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.
IIRC recognizers was a c.l.f invention.-a Each forth, it was noted, had
its own way
of integrating floating-point into the system - fp being an 'optional
extension'
of Forth-94.-a Typically integration was achieved through hooks the
system designer
had purposely built into system.-a Forth-94 had already defined how the
forth
interpreter should handle fp numbers.-a Parsing words F# etc were not
an option.
WIBN (wouldn't it be nice) it was argued if these hooks into the
interpreter could
be made portable.-a It caught the imagination of sufficient users (in
forth there's
little distinction between user and system-designer) and the rest is
history.
Recognizers were sufficiently complicated prompting more justification
than fp (1)
in order to sell it.-a It was 'a solution in search of a problem'.
From that came
the idea that forth should be able to parse *anything* - however
unlikely or little
used.
(1) While fp integration prompted recognizers, recognizers were never
a complete
solution.-a Integrating fp into a system often requires more than
simply making the
interpreter recognize fp numbers.-a System-specific hooks remain.
From that came
the idea that forth should be able to parse *anything* - however
unlikely or little
used.
I was a bit surprised that "a space delimits 'symbols'" has not been
made more flexible...
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).-a OTOH, if you find
any mistakes, missing parts or unclear parts, now is the time when
your input will be most effective.-a 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%
-a-a bl word count >float 0= abort" Bad float"
-a-a 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"?
"DonrCOt write your own interpreter/compiler when you can use ForthrCOs.
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 whatrCOs 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.
-a-a-a J^n
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).-a OTOH, if you find
any mistakes, missing parts or unclear parts, now is the time when
your input will be most effective.-a 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%
-a-a bl word count >float 0= abort" Bad float"
-a-a 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"?
"DonrCOt write your own interpreter/compiler when you can use ForthrCOs. >>> 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 whatrCOs 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.
-a-a-a-a J^n
Maybe because you have no idea how this thing works.
On 11/02/2026 4:48 am, jkn wrote:
...
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.
IIRC recognizers was a c.l.f invention. Each forth, it was noted, had its own way
of integrating floating-point into the system - fp being an 'optional extension'
of Forth-94. Typically integration was achieved through hooks the system designer
had purposely built into system. Forth-94 had already defined how the forth interpreter should handle fp numbers. Parsing words F# etc were not an option.
WIBN (wouldn't it be nice) it was argued if these hooks into the interpreter could
be made portable. It caught the imagination of sufficient users (in forth there's
little distinction between user and system-designer) and the rest is history. Recognizers were sufficiently complicated prompting more justification than fp (1)
in order to sell it. It was 'a solution in search of a problem'. From that came
the idea that forth should be able to parse *anything* - however unlikely or little
used.
(1) While fp integration prompted recognizers, recognizers were never a complete
solution. Integrating fp into a system often requires more than simply making the
interpreter recognize fp numbers. System-specific hooks remain.
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).-a OTOH, if you find >>>>> any mistakes, missing parts or unclear parts, now is the time when
your input will be most effective.-a 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%
-a-a bl word count >float 0= abort" Bad float"
-a-a 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"?
"DonrCOt write your own interpreter/compiler when you can use ForthrCOs. >>>> 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 whatrCOs 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.
-a-a-a-a 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...
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.
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.
I was a bit surprised that "a space delimits 'symbols'" has not been
made more flexible...
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).-a OTOH, if you find >>>>>> any mistakes, missing parts or unclear parts, now is the time when >>>>>> your input will be most effective.-a 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%
-a-a bl word count >float 0= abort" Bad float"
-a-a 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"?
"DonrCOt write your own interpreter/compiler when you can use
ForthrCOs. 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 whatrCOs
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.
-a-a-a-a 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
On 11-02-2026 10:05, jkn wrote:
On 11/02/2026 00:21, dxf wrote:
On 11/02/2026 4:48 am, jkn wrote:
...
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.
IIRC recognizers was a c.l.f invention.-a Each forth, it was noted,
had its own way
of integrating floating-point into the system - fp being an 'optional
extension'
of Forth-94.-a Typically integration was achieved through hooks the
system designer
had purposely built into system.-a Forth-94 had already defined how
the forth
interpreter should handle fp numbers.-a Parsing words F# etc were not
an option.
WIBN (wouldn't it be nice) it was argued if these hooks into the
interpreter could
be made portable.-a It caught the imagination of sufficient users (in
forth there's
little distinction between user and system-designer) and the rest is
history.
Recognizers were sufficiently complicated prompting more
justification than fp (1)
in order to sell it.-a It was 'a solution in search of a problem'.
From that came
the idea that forth should be able to parse *anything* - however
unlikely or little
used.
(1) While fp integration prompted recognizers, recognizers were never
a complete
solution.-a Integrating fp into a system often requires more than
simply making the
interpreter recognize fp numbers.-a System-specific hooks remain.
From that came
the idea that forth should be able to parse *anything* - however
unlikely or little
used.
I was a bit surprised that "a space delimits 'symbols'" has not been
made more flexible...
IMHO it has. PARSE allows you to parse for any delimiter. Some have PARSE-WORD that allows skipping leading delimiters. There is also a dedicated white-space parser called PARSE-NAME.
4tH has a word called OMIT which only skips leading delimiters without parsing anything.
Hans Bezemer
On 11-02-2026 01:21, dxf wrote:
On 11/02/2026 4:48 am, jkn wrote:
...
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.
IIRC recognizers was a c.l.f invention.-a Each forth, it was noted, had its own way
of integrating floating-point into the system - fp being an 'optional extension'
of Forth-94.-a Typically integration was achieved through hooks the system designer
had purposely built into system.-a Forth-94 had already defined how the forth
interpreter should handle fp numbers.-a Parsing words F# etc were not an option.
WIBN (wouldn't it be nice) it was argued if these hooks into the interpreter could
be made portable.-a It caught the imagination of sufficient users (in forth there's
little distinction between user and system-designer) and the rest is history.
Recognizers were sufficiently complicated prompting more justification than fp (1)
in order to sell it.-a It was 'a solution in search of a problem'.-a From that came
the idea that forth should be able to parse *anything* - however unlikely or little
used.
(1) While fp integration prompted recognizers, recognizers were never a complete
solution.-a Integrating fp into a system often requires more than simply making the
interpreter recognize fp numbers.-a System-specific hooks remain.
Extending the functionality of already defined words (in previous wordsets) was always a weak point of ANS-94. I don't know if other language standards use this, but I don't feel comfortable with "redefining" or "extending" words.
BTW, S" is one of the few examples of words that are not stateless (contrary to CHAR and [CHAR], ' and ['], ." and .( etc.).
They could have spared us a lot of trouble defining S( - or whatever. But consistency has never been Forth's strong point, unfortunately. It's always trends that are aborted half way, because the maintenance efforts are getting out of hand.
This discrepancy between pragmatism and "a brave new world" becomes painfully clear when reading section 12.3.7:
"If the Floating-Point word set is present in the dictionary and the current base is DECIMAL, the input number-conversion algorithm shall be extended to recognize floating-point numbers."
Which means you have to do an overhaul of the text interpreter. Which is a HORRIBLE requirement!
And its rationale:
"A.12.3.7 Text interpreter input number conversion. The Technical Committee has more than once received the suggestion that the text interpreter in Standard Forth systems should treat numbers that have an embedded decimal point, but no exponent, as floating-point numbers rather than double cell numbers. This suggestion, although it has merit, has always been voted down because it would break too much existing code; many existing implementations put the full digit string on the stack as a double number and use other means to inform the application of the location of the decimal point."
It would have been better if such requirement had NOT existed and (as ugly as it is) S" 12.34e" >FLOAT had remained the only accepted way to enter an FP number - OR a word like F% or F# had been brought into existence for the time being.
I still think that meddling with the text interpreter is a big no-no and an invitation to disaster. Never leave to a computer that which a programmer can signify as his intent. Although I'm still not dancing on the table, that is at least one of the characteristics of Alberts proposal (and it leaves the text interpreter largely intact!)
I get it but IMO f/p isn't something one simply LOADs - even if
Forth-94 sold it that way as a nod to minimalists. With the
exception of folks like me (and perhaps you) who want to be able to
load a variety of f/p packs, f/p is there when one boots forth.
Extending the functionality of already defined words (in previous
wordsets) was always a weak point of ANS-94. I don't know if other
language standards use this, but I don't feel comfortable with
"redefining" or "extending" words.
I still think that meddling with the text interpreter is a big no-no and
an invitation to disaster. Never leave to a computer that which a
programmer can signify as his intent.
Hans Bezemer <the.beez.speaks@gmail.com> writes:
Extending the functionality of already defined words (in previous
wordsets) was always a weak point of ANS-94. I don't know if other
language standards use this, but I don't feel comfortable with
"redefining" or "extending" words.
Most other standards don't try to cater to small implementations as
much as the Forth standard does. It's pretty pointless, though: Big implementations implement almost everything, and small implementations
pick and choose from the standard requirements anyway, even among the requirements for CORE words. The CORE wordset has only been a
goalpost for peoplle who implement Forth as an exercise.
I still think that meddling with the text interpreter is a big no-no and
an invitation to disaster. Never leave to a computer that which a
programmer can signify as his intent.
Recognizers provide additional ways for programmers to signify as
their intent.
- anton
dxf <dxforth@gmail.com> writes:
[reformatted to Usenet standards]
I get it but IMO f/p isn't something one simply LOADs - even if
Forth-94 sold it that way as a nod to minimalists. With the
exception of folks like me (and perhaps you) who want to be able to
load a variety of f/p packs, f/p is there when one boots forth.
SwiftForth before 4.0 (which was only released on 22-Oct-2025) does
not include the FP wordset by default. VFX Forth before release 5
(released on 24 August 2018) does not include the FP wordset by
default. SwiftForth 4.x and VFX 5.x include the FP wordset by
default.
Gforth, iForth, and lxf included the FP wordset by default in all
versions that I have tested.
- anton
dxf <dxforth@gmail.com> writes:
[reformatted to Usenet standards]
I get it but IMO f/p isn't something one simply LOADs - even if
Forth-94 sold it that way as a nod to minimalists. With the
exception of folks like me (and perhaps you) who want to be able to
load a variety of f/p packs, f/p is there when one boots forth.
SwiftForth before 4.0 (which was only released on 22-Oct-2025) does
not include the FP wordset by default. VFX Forth before release 5
(released on 24 August 2018) does not include the FP wordset by
default.
SwiftForth 4.x and VFX 5.x include the FP wordset by
default.
Gforth, iForth, and lxf included the FP wordset by default in all
versions that I have tested.
- anton
On 12-02-2026 08:24, Anton Ertl wrote:...
Gforth, iForth, and lxf included the FP wordset by default in all
versions that I have tested.
Neither does 4tH. But that those are already included might be a logical >result of recognizing FP numbers in the text interpreter.
Think of it:
why implement that in a CORE compiler?
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
Forth would be awkward to work with when you need a thing like "S%"
every single line."
On 12-02-2026 08:35, Anton Ertl wrote:...
[...] small implementations
pick and choose from the standard requirements anyway, even among the
requirements for CORE words. The CORE wordset has only been a
goalpost for peoplle who implement Forth as an exercise.
I don't think that people who are "implementing Forth as an exercise"
can be bothered to make it "a standard compiler".
And although wordsets build modularity (which I welcome) it becomes
useless when it requires you to patch wordsets already implemented.
jkn <jkn+nin@nicorp.co.uk> writes:
I was a bit surprised that "a space delimits 'symbols'" has not been
made more flexible...
Lack of demand. For Forth source white space as delimiter is deeply
rooted, and I have not seen any desire to change that. Bernd Paysan
has used the text interpreter with appropriate recognizers for parsing
other kinds of input (e.g., .ini files), but I have not heard any
desire to change the parsing part of the text interpreter, either. In
any case, the recognizers work with what comes out of the parsing
part, so changing the parsing part would be a separate, mostly
independent proposal.
- anton
On 12/02/2026 12:34 am, Hans Bezemer wrote:
On 11-02-2026 01:21, dxf wrote:standards use this, but I don't feel comfortable with "redefining" or "extending" words.
On 11/02/2026 4:48 am, jkn wrote:
...
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.
IIRC recognizers was a c.l.f invention.-a Each forth, it was noted, had its own way
of integrating floating-point into the system - fp being an 'optional extension'
of Forth-94.-a Typically integration was achieved through hooks the system designer
had purposely built into system.-a Forth-94 had already defined how the forth
interpreter should handle fp numbers.-a Parsing words F# etc were not an option.
WIBN (wouldn't it be nice) it was argued if these hooks into the interpreter could
be made portable.-a It caught the imagination of sufficient users (in forth there's
little distinction between user and system-designer) and the rest is history.
Recognizers were sufficiently complicated prompting more justification than fp (1)
in order to sell it.-a It was 'a solution in search of a problem'.-a From that came
the idea that forth should be able to parse *anything* - however unlikely or little
used.
(1) While fp integration prompted recognizers, recognizers were never a complete
solution.-a Integrating fp into a system often requires more than simply making the
interpreter recognize fp numbers.-a System-specific hooks remain.
Extending the functionality of already defined words (in previous wordsets) was always a weak point of ANS-94. I don't know if other language
It's always trends that are aborted half way, because the maintenance efforts are getting out of hand.
BTW, S" is one of the few examples of words that are not stateless (contrary to CHAR and [CHAR], ' and ['], ." and .( etc.).
They could have spared us a lot of trouble defining S( - or whatever. But consistency has never been Forth's strong point, unfortunately.
extended to recognize floating-point numbers."
This discrepancy between pragmatism and "a brave new world" becomes painfully clear when reading section 12.3.7:
"If the Floating-Point word set is present in the dictionary and the current base is DECIMAL, the input number-conversion algorithm shall be
interpreter in Standard Forth systems should treat numbers that have an embedded decimal point, but no exponent, as floating-point numbers
Which means you have to do an overhaul of the text interpreter. Which is a HORRIBLE requirement!
And its rationale:
"A.12.3.7 Text interpreter input number conversion. The Technical Committee has more than once received the suggestion that the text
rather than double cell numbers. This suggestion, although it has merit, has always been voted down because it would break too much existing
code; many existing implementations put the full digit string on the stack as a double number and use other means to inform the application of
the location of the decimal point."
enter an FP number - OR a word like F% or F# had been brought into existence for the time being.
It would have been better if such requirement had NOT existed and (as ugly as it is) S" 12.34e" >FLOAT had remained the only accepted way to
I would say by the time ANS-TC began its deliberations the die had already been cast.
The 'Standard Floating Point Extension' published in 1985 by the Forth Vendors Group
(LMI and Micromotion with input from several vendors) required input in the form:
If the floating point extension word set has been overlaid onto a
83-Standard Forth system, a string of the following form will be
compiled or interpreted as a real number:
nnnn.nnnExx
The "E" signifier is mandatory to force the conversion of a real
number. The presence of numeric digits before or after the "E"
is not required by this specification but may be mandatory in
some implementations. A "-" sign may precede both the mantissa
and the exponent, a leading "+" sign is also permissible on the
exponent. A decimal point is optional and occur anywhere in the
mantissa. For example, all of the following numbers are legal:
-.0001E5
100.0E+0
1000.E-15
After Forth-83 which split vendors, ANS-TC wasn't going to do anything that drew the
ire of an existing user base. One only has to look at the flack Forth-94 received
when a section of existing locals users didn't get what they were expecting.
I still think that meddling with the text interpreter is a big no-no and an invitation to disaster. Never leave to a computer that which aprogrammer can signify as his intent. Although I'm still not dancing on the table, that is at least one of the characteristics of Alberts
proposal (and it leaves the text interpreter largely intact!)
I get it but IMO f/p isn't something one simply LOADs - even if Forth-94 sold it that
way as a nod to minimalists. With the exception of folks like me (and perhaps you)
who want to be able to load a variety of f/p packs, f/p is there when one boots forth.
What the eyes don't see, the heart doesn't grieve.
On 12-02-2026 08:24, Anton Ertl wrote:
dxf <dxforth@gmail.com> writes:
[reformatted to Usenet standards]
I get it but IMO f/p isn't something one simply LOADs - even if
Forth-94 sold it that way as a nod to minimalists. With the
exception of folks like me (and perhaps you) who want to be able to
load a variety of f/p packs, f/p is there when one boots forth.
SwiftForth before 4.0 (which was only released on 22-Oct-2025) does
not include the FP wordset by default. VFX Forth before release 5
(released on 24 August 2018) does not include the FP wordset by
default. SwiftForth 4.x and VFX 5.x include the FP wordset by
default.
Gforth, iForth, and lxf included the FP wordset by default in all
versions that I have tested.
- anton
Neither does 4tH. But that those are already included might be a logical >result of recognizing FP numbers in the text interpreter. Think of it:
why implement that in a CORE compiler? To what should it compile?
Especially since that would require an FP stack (since other
implementations have been outlawed since).
Hans Bezemer--
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:
Hans Bezemer--
In article <698d205a$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 12/02/2026 12:34 am, Hans Bezemer wrote:
On 11-02-2026 01:21, dxf wrote:standards use this, but I don't feel comfortable with "redefining" or "extending" words.
On 11/02/2026 4:48 am, jkn wrote:
...
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.
IIRC recognizers was a c.l.f invention.-a Each forth, it was noted, had its own way
of integrating floating-point into the system - fp being an 'optional extension'
of Forth-94.-a Typically integration was achieved through hooks the system designer
had purposely built into system.-a Forth-94 had already defined how the forth
interpreter should handle fp numbers.-a Parsing words F# etc were not an option.
WIBN (wouldn't it be nice) it was argued if these hooks into the interpreter could
be made portable.-a It caught the imagination of sufficient users (in forth there's
little distinction between user and system-designer) and the rest is history.
Recognizers were sufficiently complicated prompting more justification than fp (1)
in order to sell it.-a It was 'a solution in search of a problem'.-a From that came
the idea that forth should be able to parse *anything* - however unlikely or little
used.
(1) While fp integration prompted recognizers, recognizers were never a complete
solution.-a Integrating fp into a system often requires more than simply making the
interpreter recognize fp numbers.-a System-specific hooks remain.
Extending the functionality of already defined words (in previous wordsets) was always a weak point of ANS-94. I don't know if other language
It's always trends that are aborted half way, because the maintenance efforts are getting out of hand.
BTW, S" is one of the few examples of words that are not stateless (contrary to CHAR and [CHAR], ' and ['], ." and .( etc.).
They could have spared us a lot of trouble defining S( - or whatever. But consistency has never been Forth's strong point, unfortunately.
extended to recognize floating-point numbers."
This discrepancy between pragmatism and "a brave new world" becomes painfully clear when reading section 12.3.7:
"If the Floating-Point word set is present in the dictionary and the current base is DECIMAL, the input number-conversion algorithm shall be
interpreter in Standard Forth systems should treat numbers that have an embedded decimal point, but no exponent, as floating-point numbers
Which means you have to do an overhaul of the text interpreter. Which is a HORRIBLE requirement!
And its rationale:
"A.12.3.7 Text interpreter input number conversion. The Technical Committee has more than once received the suggestion that the text
rather than double cell numbers. This suggestion, although it has merit, has always been voted down because it would break too much existing
code; many existing implementations put the full digit string on the stack as a double number and use other means to inform the application of
the location of the decimal point."
enter an FP number - OR a word like F% or F# had been brought into existence for the time being.
It would have been better if such requirement had NOT existed and (as ugly as it is) S" 12.34e" >FLOAT had remained the only accepted way to
I would say by the time ANS-TC began its deliberations the die had already been cast.
The 'Standard Floating Point Extension' published in 1985 by the Forth Vendors Group
(LMI and Micromotion with input from several vendors) required input in the form:
If the floating point extension word set has been overlaid onto a
83-Standard Forth system, a string of the following form will be
compiled or interpreted as a real number:
nnnn.nnnExx
The "E" signifier is mandatory to force the conversion of a real
number. The presence of numeric digits before or after the "E"
is not required by this specification but may be mandatory in
some implementations. A "-" sign may precede both the mantissa
and the exponent, a leading "+" sign is also permissible on the
exponent. A decimal point is optional and occur anywhere in the
mantissa. For example, all of the following numbers are legal:
-.0001E5
100.0E+0
1000.E-15
After Forth-83 which split vendors, ANS-TC wasn't going to do anything that drew the
ire of an existing user base. One only has to look at the flack Forth-94 received
when a section of existing locals users didn't get what they were expecting. >>
I still think that meddling with the text interpreter is a big no-no and an invitation to disaster. Never leave to a computer that which aprogrammer can signify as his intent. Although I'm still not dancing on the table, that is at least one of the characteristics of Alberts
proposal (and it leaves the text interpreter largely intact!)
I get it but IMO f/p isn't something one simply LOADs - even if Forth-94 sold it that
way as a nod to minimalists. With the exception of folks like me (and perhaps you)
who want to be able to load a variety of f/p packs, f/p is there when one boots forth.
What the eyes don't see, the heart doesn't grieve.
With the diminishing importance of double integers, I would support
the idea if requiring a decimal point as the start *and* end of a double precision number.
.10000000000000000000.
Now any number containing one decimal point can safely be considered a floating point number.
Also E as the exponent is a design error. The twiggle is ideal,
it support a 126 base. BASE 16 is ideal to eliminate rounding errors
during transfers over asci channels.
Groetjes Albert
When I designed 4tH, I got rid of double numbers (and consequently,
mixed numbers as well). Yeah, they have their use in the 16 bit era -
but not anymore. FYI - that was 1994.
In the 64-bit era, I think we could get rid of double numbers
altogether. Dump the whole thing in a separate wordset and be done with
it. Clean up CORE.
"Yeah, but don't you know how much code would get broken?" Yeah, I've
heard that song before. Let's keep dragging all that old stuff along
till eternity. You can never have enough technical depth, can you.
What about a wordset "OBSOLETE", where we can dump all that stuff. Like
WORD, QUERY, EXPECT, CONVERT? So people can still compile their old
stuff without lifting a finger?
Hans Bezemer
Hans Bezemer <the.beez.speaks@gmail.com> writes:
On 12-02-2026 08:35, Anton Ertl wrote:...
[...] small implementations
pick and choose from the standard requirements anyway, even among the
requirements for CORE words. The CORE wordset has only been a
goalpost for peoplle who implement Forth as an exercise.
I don't think that people who are "implementing Forth as an exercise"
can be bothered to make it "a standard compiler".
The point is not standard conformance, but a goalpost: To have
something to direct the work, and also to have something that tells
the implementor when the project is complete.
And although wordsets build modularity (which I welcome) it becomes
useless when it requires you to patch wordsets already implemented.
Who is "you" in this sentence? Given that you write "implemented",
you seem to argue that the standard requires the system implementor to implement the base word, and then to patch it. This is not the case.
The system implementor who has decided to implement the FILE words in addition to the CORE words can implement the FILE version of S" from
the start, without any patching.
Note also that the FILE version of S" conforms to the requirements for
the CORE version of S", and that's generally the case for the extended versions of words. E.g., the specification of CORE's POSTPONE
includes
| An ambiguous condition exists if name is not found.
so it does not specify what "POSTPONE 123" means. The proposed
recognizer version of POSTPONE specifies that.
- anton
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
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.
On 13-02-2026 09:27, Anton Ertl wrote:
Hans Bezemer <the.beez.speaks@gmail.com> writes:
On 12-02-2026 08:35, Anton Ertl wrote:...
[...] small implementations
pick and choose from the standard requirements anyway, even among the
requirements for CORE words.-a The CORE wordset has only been a
goalpost for peoplle who implement Forth as an exercise.
I don't think that people who are "implementing Forth as an exercise"
can be bothered to make it "a standard compiler".
The point is not standard conformance, but a goalpost: To have
something to direct the work, and also to have something that tells
the implementor when the project is complete.
And although wordsets build modularity (which I welcome) it becomes
useless when it requires you to patch wordsets already implemented.
Who is "you" in this sentence?-a Given that you write "implemented",
you seem to argue that the standard requires the system implementor to
implement the base word, and then to patch it.-a This is not the case.
The system implementor who has decided to implement the FILE words in
addition to the CORE words can implement the FILE version of S" from
the start, without any patching.
Note also that the FILE version of S" conforms to the requirements for
the CORE version of S", and that's generally the case for the extended
versions of words.-a E.g., the specification of CORE's POSTPONE
includes
| An ambiguous condition exists if name is not found.
so it does not specify what "POSTPONE 123" means.-a The proposed
recognizer version of POSTPONE specifies that.
- anton
I could have used "one" - wouldn't have changed the meaning. Nice "Whataboutism"! The argument was (and is) what use has a standard for a
toy compiler?
"Anton") overestimate the authority of a standards body greatly.
Especially when the language concerned is almost dead. There are more
people implementing that compiler than writing programs for it!
And yes - it often happens (I speak from my own experience) that "one"
(now clear for you? :) thinks - "that's as far as I want/need to go" and consider otherwise later. And yeah, then "one" has to patch it. Because
the word *IS* already defined "one" has to extend its functionality.
"An ambiguous condition exists if name is not found."
That's not a point I addressed. (Not "one").I just looked on GitHub
Hans Bezemer
On 13/02/2026 12:43, Hans Bezemer wrote:
On 13-02-2026 09:27, Anton Ertl wrote:
Hans Bezemer <the.beez.speaks@gmail.com> writes:
On 12-02-2026 08:35, Anton Ertl wrote:...
[...] small implementations
pick and choose from the standard requirements anyway, even among the >>>>> requirements for CORE words.-a The CORE wordset has only been a
goalpost for peoplle who implement Forth as an exercise.
I don't think that people who are "implementing Forth as an exercise"
can be bothered to make it "a standard compiler".
The point is not standard conformance, but a goalpost: To have
something to direct the work, and also to have something that tells
the implementor when the project is complete.
And although wordsets build modularity (which I welcome) it becomes
useless when it requires you to patch wordsets already implemented.
Who is "you" in this sentence?-a Given that you write "implemented",
you seem to argue that the standard requires the system implementor to
implement the base word, and then to patch it.-a This is not the case.
The system implementor who has decided to implement the FILE words in
addition to the CORE words can implement the FILE version of S" from
the start, without any patching.
Note also that the FILE version of S" conforms to the requirements for
the CORE version of S", and that's generally the case for the extended
versions of words.-a E.g., the specification of CORE's POSTPONE
includes
| An ambiguous condition exists if name is not found.
so it does not specify what "POSTPONE 123" means.-a The proposed
recognizer version of POSTPONE specifies that.
- anton
I could have used "one" - wouldn't have changed the meaning. Nice "Whataboutism"! The argument was (and is) what use has a standard for a toy compiler?
There's another point I think you're missing. I just looked on at my Forth test suite on GitHub and 78 people have found it useful enough to give it a star. I've no idea whether they are all developing their own "toy" system but I would guess most are, and their system has to have some testing. I suggest that the easiest way is to use an existing test suite. As far as I know there is only one, so that automatically leads them to make their system (at least partially) standard compliant. An unexpected (and unintended) consequence of having a test suite.
On 14/02/2026 10:50 am, Gerry Jackson wrote:
On 13/02/2026 12:43, Hans Bezemer wrote:toy compiler?
On 13-02-2026 09:27, Anton Ertl wrote:
Hans Bezemer <the.beez.speaks@gmail.com> writes:
On 12-02-2026 08:35, Anton Ertl wrote:...
[...] small implementations
pick and choose from the standard requirements anyway, even among the >>>>>> requirements for CORE words.-a The CORE wordset has only been a
goalpost for peoplle who implement Forth as an exercise.
I don't think that people who are "implementing Forth as an exercise" >>>>> can be bothered to make it "a standard compiler".
The point is not standard conformance, but a goalpost: To have
something to direct the work, and also to have something that tells
the implementor when the project is complete.
And although wordsets build modularity (which I welcome) it becomes
useless when it requires you to patch wordsets already implemented.
Who is "you" in this sentence?-a Given that you write "implemented",
you seem to argue that the standard requires the system implementor to >>>> implement the base word, and then to patch it.-a This is not the case. >>>> The system implementor who has decided to implement the FILE words in
addition to the CORE words can implement the FILE version of S" from
the start, without any patching.
Note also that the FILE version of S" conforms to the requirements for >>>> the CORE version of S", and that's generally the case for the extended >>>> versions of words.-a E.g., the specification of CORE's POSTPONE
includes
| An ambiguous condition exists if name is not found.
so it does not specify what "POSTPONE 123" means.-a The proposed
recognizer version of POSTPONE specifies that.
- anton
I could have used "one" - wouldn't have changed the meaning. Nice "Whataboutism"! The argument was (and is) what use has a standard for a
give it a star. I've no idea whether they are all developing their own "toy" system but I would guess most are, and their system has to have
There's another point I think you're missing. I just looked on at my Forth test suite on GitHub and 78 people have found it useful enough to
some testing. I suggest that the easiest way is to use an existing test suite. As far as I know there is only one, so that automatically leads
them to make their system (at least partially) standard compliant. An unexpected (and unintended) consequence of having a test suite.
Cart before horse but I agree. First-time creators will generally pick some >standard or system because it's the easiest way. All the thinking has been >done for one and there's a wealth of existing source from which to choose or >use as a guide. It's a rare lion that hasn't undertaken internship as a camel.
Moore appears to have been a rebel, lone wolf, from the beginning for whom >conformity was anathema, stagnation.
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/
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.
...
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
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 ;-)
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
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.
...
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.
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.
- antonGroetjes Albert
On 14/02/2026 10:50 am, Gerry Jackson wrote:
On 13/02/2026 12:43, Hans Bezemer wrote:
On 13-02-2026 09:27, Anton Ertl wrote:
Hans Bezemer <the.beez.speaks@gmail.com> writes:
On 12-02-2026 08:35, Anton Ertl wrote:...
[...] small implementations
pick and choose from the standard requirements anyway, even among the >>>>>> requirements for CORE words.-a The CORE wordset has only been a
goalpost for peoplle who implement Forth as an exercise.
I don't think that people who are "implementing Forth as an exercise" >>>>> can be bothered to make it "a standard compiler".
The point is not standard conformance, but a goalpost: To have
something to direct the work, and also to have something that tells
the implementor when the project is complete.
And although wordsets build modularity (which I welcome) it becomes
useless when it requires you to patch wordsets already implemented.
Who is "you" in this sentence?-a Given that you write "implemented",
you seem to argue that the standard requires the system implementor to >>>> implement the base word, and then to patch it.-a This is not the case. >>>> The system implementor who has decided to implement the FILE words in
addition to the CORE words can implement the FILE version of S" from
the start, without any patching.
Note also that the FILE version of S" conforms to the requirements for >>>> the CORE version of S", and that's generally the case for the extended >>>> versions of words.-a E.g., the specification of CORE's POSTPONE
includes
| An ambiguous condition exists if name is not found.
so it does not specify what "POSTPONE 123" means.-a The proposed
recognizer version of POSTPONE specifies that.
- anton
I could have used "one" - wouldn't have changed the meaning. Nice "Whataboutism"! The argument was (and is) what use has a standard for a toy compiler?
There's another point I think you're missing. I just looked on at my Forth test suite on GitHub and 78 people have found it useful enough to give it a star. I've no idea whether they are all developing their own "toy" system but I would guess most are, and their system has to have some testing. I suggest that the easiest way is to use an existing test suite. As far as I know there is only one, so that automatically leads them to make their system (at least partially) standard compliant. An unexpected (and unintended) consequence of having a test suite.
Cart before horse but I agree. First-time creators will generally pick some standard or system because it's the easiest way. All the thinking has been done for one and there's a wealth of existing source from which to choose or use as a guide. It's a rare lion that hasn't undertaken internship as a camel.
Moore appears to have been a rebel, lone wolf, from the beginning for whom conformity was anathema, stagnation.
On 14-02-2026 02:53, dxf wrote:
Cart before horse but I agree. First-time creators will generally pick some >> standard or system because it's the easiest way. All the thinking has been >> done for one and there's a wealth of existing source from which to choose or >> use as a guide. It's a rare lion that hasn't undertaken internship as a camel.
Moore appears to have been a rebel, lone wolf, from the beginning for whom >> conformity was anathema, stagnation.
Read what you're saying: "SOME standard or system". Not necessarily an >ANS-kind of system. I think a newbie will rather rip something from the
web that works and use that as a template than take a paper standard and
try to replicate that one.
If I dig into my own history - I took the Forth-79 standard, took the
most essential parts from it and started from there - AKA it wasn't even
a FULL Forth-79 system. The move to ANS started several versions later.
So no - I don't swallow the argument "a CORE wordset is useful for bare >implementations". I even wonder if they take a look at all. Or if they
even care. If I may believe the presentations of recent Forth
experiments, not at all.
Hans Bezemer
...
Willem Ouwerkerk c.s. developed many Forths for small SBC (8051, etc.)
This was done with a so called metacompiler. Once you get used to
this tool, it is comparitively easy to port to new microprocessors.
In this development path, the first thing you do is to write a
Forth assembler for the new processor, then insert the uP-dependant
stuff into the metacompiler tool.
In this way the meta sources determine what is present, possibly
a bit idiosyncratic.
I consider my assembler sources more valuable than an open source metacompiler system, so I choose that route.
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?
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.
: 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.
Note - in those days, late seventies, early
eighties, floating point numbers were unheard of.
At that time, 32-bit
numbers were unheard of.
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).
Hans Bezemer <the.beez.speaks@gmail.com> writes:
On 12-02-2026 08:24, Anton Ertl wrote:...
Gforth, iForth, and lxf included the FP wordset by default in all
versions that I have tested.
Neither does 4tH. But that those are already included might be a logical
result of recognizing FP numbers in the text interpreter.
Counterexample: Gforth 0.7 (before recognizers): Here the text
interpreter for one word contains hard-coded stuff for dealing with
words (FIND-NAME) and with single and double-cell numbers (SNUMBER?),
but nothing for floating-point. Instead, there are hooks INTERPRETER-NOTFOUND1 and COMPILER-NOTFOUND1, and when float.fs is
loaded, recognizing floating-point words is added to these hooks.
\ called in interpretation state
: interpreter1 ( c-addr u -- ... xt )
2dup find-name dup
if
nip nip name>int
else
drop
2dup 2>r snumber?
IF
2rdrop ['] noop
ELSE
2r> interpreter-notfound1
THEN
then ;
\ called in compilation state
: compiler1 ( c-addr u -- ... xt )
2dup find-name dup
if ( c-addr u nt )
nip nip name>comp
else
drop
2dup 2>r snumber? dup
IF
0>
IF
['] 2literal
ELSE
['] literal
THEN
2rdrop
ELSE
drop 2r> compiler-notfound1
THEN
then ;
The decision to not have FP in the hard-coded part of the text
interpreter was taken by Bernd Paysan, so I can only guess why he did
that: My guess is that this text interpreter was originally also used
for Gforth EC for small CPUs without hardware FP support where Gforth
does not implement FP.
Another reason might be (certainly for me) that the hard-coded text interpreter is in the cross-compiled part of Gforth, whereas float.fs
(which includes the thing that plugs into the text interpreter) is in
the part of Gforth that is compiled with Gforth's regular compiler. I
found the latter always significantly easier to use than the
cross-compiler and have always tried to keep the amount of code and
changes in the cross-compiled portion of Gforth small.
Counterexamples: Gforth (development), SwiftForth 4.x and VFX 5.x:
Their text interpreters are recognizer-based, so recognizing FP is not hard-coded into the text interpreter at all (nor is recognizing words
or integers).
Concerning iForth and lxf, I don't know what they are doing, but I
would not be surprised if FP is not hard-coded into their text
interpreters.
While I show the example above from Gforth 0.7, here are the
corresponding recognizers REC-NAME and REC-NUMBER from in the current reference implementation of recognizers:
: undefined-word ( -- )
#-13 throw ;
' undefined-word dup dup translate: translate-none
: nop ;
: lit, ( n -- )
postpone literal ;
: litlit, ( n -- )
lit, postpone lit, ;
' nop ' lit, ' litlit, translate: translate-cell
: 2lit, ( n1 n2 -- )
postpone 2literal ;
: 2lit2lit, ( n1 n2 -- )
2lit, postpone 2lit, ;
' nop ' 2lit, ' 2lit2lit, translate: translate-dcell
: name-int ( ... nt -- ... )
name>interpret execute ;
: name-comp ( ... nt -- ... )
name>compile execute ;
: name-post ( nt -- )
lit, postpone name-comp ;
' name-int ' name-comp ' name-post translate: translate-name
: rec-name ( c-addr u -- translation )
find-name dup if
translate-name
else
drop translate-none
then ;
: rec-number ( c-addr u -- translation )
snumber? case
0 of translate-none endof
-1 of translate-cell endof
translate-dcell swap
endcase ;
Not shorter, but more factored, and supports postponing numbers.
Think of it:
why implement that in a CORE compiler?
Are you just producing a counterargument for your claim above?
- anton
On 20/02/2026 12:38 am, albert@spenarnc.xs4all.nl wrote:
...
Willem Ouwerkerk c.s. developed many Forths for small SBC (8051, etc.)
This was done with a so called metacompiler. Once you get used to
this tool, it is comparitively easy to port to new microprocessors.
In this development path, the first thing you do is to write a
Forth assembler for the new processor, then insert the uP-dependant
stuff into the metacompiler tool.
In this way the meta sources determine what is present, possibly
a bit idiosyncratic.
I consider my assembler sources more valuable than an open source
metacompiler system, so I choose that route.
Not only was native assembler easier for me as I mentioned, it was >considerably faster. Running the F83 metacompiler on a 4MHz Z80 was >painfully slow. On top of this I'd have needed to modify it to do
dictionary segmenting - my prime motivation in creating a forth.
Even the ubiquitous M80 CP/M assembler proved too slow and I invested
in an SLR Systems assembler. Given the number of compiles I did in >development it was easily the best money I ever spent on software.
Not that I wasn't forced to learn new stuff. Macros, code segmentation,
etc gave me enough headaches. Looking back it seems crazy. No regrets >however as I began to realize this was more my niche than writing >applications. That said, if one doesn't write apps there's no way to >evaluate the effectiveness of a given forth. How many forths never got
past creation because the author's interest waned. For these the list
of words in ANS etc suffices. But the forth one uses is something else.
It's the difference between a living tree and what comprises trees.
Standards are an obsession with the latter and kind of misses the point.
On 20/02/2026 12:38 am, albert@spenarnc.xs4all.nl wrote:
...
Willem Ouwerkerk c.s. developed many Forths for small SBC (8051, etc.)
This was done with a so called metacompiler. Once you get used to
this tool, it is comparitively easy to port to new microprocessors.
In this development path, the first thing you do is to write a
Forth assembler for the new processor, then insert the uP-dependant
stuff into the metacompiler tool.
In this way the meta sources determine what is present, possibly
a bit idiosyncratic.
I consider my assembler sources more valuable than an open source
metacompiler system, so I choose that route.
Not only was native assembler easier for me as I mentioned, it was considerably faster. Running the F83 metacompiler on a 4MHz Z80 was painfully slow. On top of this I'd have needed to modify it to do
dictionary segmenting - my prime motivation in creating a forth.
Even the ubiquitous M80 CP/M assembler proved too slow and I invested
in an SLR Systems assembler. Given the number of compiles I did in development it was easily the best money I ever spent on software.
Not that I wasn't forced to learn new stuff. Macros, code segmentation,
etc gave me enough headaches. Looking back it seems crazy. No regrets however as I began to realize this was more my niche than writing applications. That said, if one doesn't write apps there's no way to evaluate the effectiveness of a given forth. How many forths never got
past creation because the author's interest waned. For these the list
of words in ANS etc suffices. But the forth one uses is something else.
It's the difference between a living tree and what comprises trees.
Standards are an obsession with the latter and kind of misses the point.
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.
This is not the time or place for criticism.
Everyone must decide for
themselves whether this flavour of recognisers is useful for their >applications.
In article <2026Feb9.084944@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> 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.
After the header Solution:
"As before the text interpreter parses a white-space-delimited string. "
2]
What does that mean in the context of:
"We gaan naar Rome" TYPE
?
Are there one or four delimiters in this string?
In section 3.4.1 parsing
"
And the number in >IN is changed to index immediately past that
delimiter, thus removing the parsed characters and the delimiter from
the parse area."
S'"1 2 DROP" EVALUATE
runs into problems with this.
This requires moving >IN moved past the non-existing delimiter.
Wouldn't it be better to simplify this to :
"
And the number in >IN is changed to index immediately past the word parsed" >1]
IN would point to the second ", not behind it. After parsing
IN would point to the ), not behind it.
In view of the requirement that WORD / PARSE-NAME is required to skip
leading delimiters this change is harmless in my opinion.
"crc.frt" R/W OPEN-FILE
Naturally the string recognizer returns the filename, and leaves >IN
pointer after the " , instead of after the first blank character after
" .
A recognizer leaves >N pointing after the part of the input stream
that has been recognized. "
How logical does that sound!
(It is in fact a tautology. The position of >IN defines for all
practical purposes what has been recognized.)
In article <6997b9e1$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 20/02/2026 12:38 am, albert@spenarnc.xs4all.nl wrote:
...
Willem Ouwerkerk c.s. developed many Forths for small SBC (8051, etc.)
This was done with a so called metacompiler. Once you get used to
this tool, it is comparitively easy to port to new microprocessors.
In this development path, the first thing you do is to write a
Forth assembler for the new processor, then insert the uP-dependant
stuff into the metacompiler tool.
In this way the meta sources determine what is present, possibly
a bit idiosyncratic.
I consider my assembler sources more valuable than an open source
metacompiler system, so I choose that route.
Not only was native assembler easier for me as I mentioned, it was
considerably faster. Running the F83 metacompiler on a 4MHz Z80 was
painfully slow. On top of this I'd have needed to modify it to do
dictionary segmenting - my prime motivation in creating a forth.
Even the ubiquitous M80 CP/M assembler proved too slow and I invested
in an SLR Systems assembler. Given the number of compiles I did in
development it was easily the best money I ever spent on software.
Not that I wasn't forced to learn new stuff. Macros, code segmentation,
etc gave me enough headaches. Looking back it seems crazy. No regrets
however as I began to realize this was more my niche than writing
applications. That said, if one doesn't write apps there's no way to
evaluate the effectiveness of a given forth. How many forths never got
past creation because the author's interest waned. For these the list
of words in ANS etc suffices. But the forth one uses is something else.
It's the difference between a living tree and what comprises trees.
Standards are an obsession with the latter and kind of misses the point.
All tools running on windows/linux are fast,
The metacompilers do not run on the sbc and take at most seconds.
Especially assemblers, building ciforth is in the milliseconds.
(What they say in a blink of an eye).
...
IMHO opinion standards are only useful if they have to be transferred - from person to person or from platform to platform. I can't say I haven't benefited from that idea in one way or another. But like you said - let's keep its true value realistic and pragmatic.
minforth <minforth@gmx.net> writes:
This is not the time or place for criticism.
I think it is time for criticism, particularly meaning 2 of <https://en.wiktionary.org/wiki/criticism> (meaning 1 is not clear to
me). Concerning the place, giving your feedback on <https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11?hideDiff#reply-1623>
would be ideal, because that provides the versions of the proposal and
the feedback in one place.
Everyone must decide for
themselves whether this flavour of recognisers is useful for their
applications.
Yes, and system implementors have to decide whether the want to
implement it.
albert@spenarnc.xs4all.nl writes:<SNIP>
Okay nice deflection. The answer is there are four space delimiters."We gaan naar Rome" TYPE
?
Are there one or four delimiters in this string?
'"We' is parsed by the text interpreter and passed to a recognizer.
You commented on the first erroneous code.S" 1 2 DROP" EVALUATE
runs into problems with this.
I have no idea what this code is supposed to mean (it's not standard
code), and what problems you see with this code.
This requires moving >IN moved past the non-existing delimiter.
Wouldn't it be better to simplify this to :
"
And the number in >IN is changed to index immediately past the word parsed" >>1]
The result would be that after parsing
s" foo"
IN would point to the second ", not behind it. After parsing
( a comment )
IN would point to the ), not behind it.
In view of the requirement that WORD / PARSE-NAME is required to skip >>leading delimiters this change is harmless in my opinion.
If you had pointed that out when PARSE-NAME was proposed for
standardization, one could have changed the proposal such that it
would not consume the trailing delimiter. Unfortunately, nobody
pointed it out at the time, and if you wanted to propose such a change
now, you would have to provide very good arguments that there are no
programs around that rely on this behaviour.
"crc.frt" R/W OPEN-FILE
Naturally the string recognizer returns the filename, and leaves >IN >>pointer after the " , instead of after the first blank character after
" .
In this case, the string recognizer does no parsing at all, and
returns a translation where the actions do not parse (the translation
coming out of rec-string performs parsing in its translation actions).
The text interpreter parses and consumes the space after the ".
A recognizer leaves >N pointing after the part of the input stream
that has been recognized. "
How logical does that sound!
(It is in fact a tautology. The position of >IN defines for all
practical purposes what has been recognized.)
Actually it has been discussed whether recognizers should change >IN,
and the consensus among the participants was that recognizers should
not change >IN. There have been suggestions of specifying that in the >standard, but given that nobody would want to enforce it, it was
decided that this should go into the rationale (note to myself: put it
in the rationale). I don't remember the exact reason (I bowed out of
that discussion), but IIRC it has to do with using recognizers in
various other tools.
- anton
I still think that meddling with the text interpreter is a big no-no
and an invitation to disaster.
Probably best to leave things as they are, and
maybe suggest a nonstandard extension to treat 123.45 as a float.
It does seem to me that with 32-bit systems widespread, double ints have >gotten less important.
With the extension turned on, to get the double int, you'd use 12345 0
or maybe something like "D# 123 45" .
Hans Bezemer <the.beez.speaks@gmail.com> writes:
I still think that meddling with the text interpreter is a big no-no
and an invitation to disaster.
Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of >"123.45" change depending on whether the floating point wordset is
loaded is also horrible. Probably best to leave things as they are, and >maybe suggest a nonstandard extension to treat 123.45 as a float. To
get a double cell you'd use
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.
It does seem to me that with 32-bit systems widespread, double ints have gotten less important. ...Double numbers are still useful on 64-bit systems, in physics,
In article <87qzq8b07r.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
Hans Bezemer <the.beez.speaks@gmail.com> writes:
I still think that meddling with the text interpreter is a big no-no
and an invitation to disaster.
Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of
"123.45" change depending on whether the floating point wordset is
loaded is also horrible. Probably best to leave things as they are, and
maybe suggest a nonstandard extension to treat 123.45 as a float. To
get a double cell you'd use
Offically 123.45 is not a double number. It should end with a decimal point.
How is the support for a proposal:
Double numbers should start and end with a dot.
Now any numbers containing a single dot are automatically fp
A program that uses single dots to indicate doubles, should
declare an environmental dependancy. The default behaviour it
that they are floats.
In this way most programs that uses fp and use single dots are
fully compliant.
There are people who are font of 01/02/03 date (2003 januari 2 )
indications that are examples in Starting Forth.
You could do this with recognizers (I suppose).
There are people who are font of 01/02/03 date (2003 januari 2 )
indications that are examples in Starting Forth.
You could do this with recognizers (I suppose).
On 26/02/2026 12:09, albert@spenarnc.xs4all.nl wrote:
There are people who are font of 01/02/03 date (2003 januari 2 )
indications that are examples in Starting Forth.
You could do this with recognizers (I suppose).
It's better to use the ISO 8601 format YYYY-MM-DD where your example
date is 2003-01-02 which is unambiguous and easy to sort.
In article <87qzq8b07r.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
Hans Bezemer <the.beez.speaks@gmail.com> writes:
I still think that meddling with the text interpreter is a big no-no
and an invitation to disaster.
Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of
"123.45" change depending on whether the floating point wordset is
loaded is also horrible. Probably best to leave things as they are, and
maybe suggest a nonstandard extension to treat 123.45 as a float. To
get a double cell you'd use
Offically 123.45 is not a double number. It should end with a decimal point.
How is the support for a proposal:
Double numbers should start and end with a dot.
Now any numbers containing a single dot are automatically fp
A program that uses single dots to indicate doubles, should
declare an environmental dependancy. The default behaviour it
that they are floats.
In this way most programs that uses fp and use single dots are
fully compliant.
There are people who are font of 01/02/03 date (2003 januari 2 )
indications that are examples in Starting Forth.
You could do this with recognizers (I suppose).
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.
I have published yourforth, an altenative to jonesforth. It is 32 bits
and I have eliminated all double precision crap, contributing to
it pedagogical value.
Groetjes Albert
...
The range of 64bit numbers covers just about everything under the sun, so I agree fullheartedly with the idea that double numbers are close to complete obsolescence. The last time I used triple numbers was when I wrote several IBAN related utilities on a 32-bit platform. Which most double number applications boils down to nowadays.
But.. I've been around here for a while and I think given there are still people using WORD and vanilla counted strings that the 22nd century Forths will still support double numbers - resulting in 1024 bit double numbers.
On 26-02-2026 13:09, albert@spenarnc.xs4all.nl wrote:
In article <87qzq8b07r.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
Hans Bezemer <the.beez.speaks@gmail.com> writes:
I still think that meddling with the text interpreter is a big no-no
and an invitation to disaster.
Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of
"123.45" change depending on whether the floating point wordset is
loaded is also horrible. Probably best to leave things as they are, and >>> maybe suggest a nonstandard extension to treat 123.45 as a float. To
get a double cell you'd use
Offically 123.45 is not a double number. It should end with a decimal point. >>
How is the support for a proposal:
Double numbers should start and end with a dot.
Now any numbers containing a single dot are automatically fp
A program that uses single dots to indicate doubles, should
declare an environmental dependancy. The default behaviour it
that they are floats.
In this way most programs that uses fp and use single dots are
fully compliant.
There are people who are font of 01/02/03 date (2003 januari 2 )
indications that are examples in Starting Forth.
You could do this with recognizers (I suppose).
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.
I have published yourforth, an altenative to jonesforth. It is 32 bits
and I have eliminated all double precision crap, contributing to
it pedagogical value.
Groetjes Albert
Although I can understand the technical, historical and pragmatic
reasons of Chuck for (a) signifying a double number by a dot and (b) the >inclusion of a double number recognizer in the text interpreter, I never >followed suit.
Double number support was NEVER part of the 4tH core - and frankly, the >initial idea was even to never support double numbers AT ALL. The
rationale behind that one was that integers at that time were 32bit
anyway - the identical precision that double numbers covered - so.. why?
The range of 64bit numbers covers just about everything under the sun,
so I agree fullheartedly with the idea that double numbers are close to >complete obsolescence. The last time I used triple numbers was when I
wrote several IBAN related utilities on a 32-bit platform. Which most
double number applications boils down to nowadays.
But.. I've been around here for a while and I think given there are
still people using WORD and vanilla counted strings that the 22nd
century Forths will still support double numbers - resulting in 1024 bit >double numbers.
Hans Bezemer
In article <nnd$73692009$4971d447@b0f461aaf5ef0059>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
On 26-02-2026 13:09, albert@spenarnc.xs4all.nl wrote:
In article <87qzq8b07r.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
Hans Bezemer <the.beez.speaks@gmail.com> writes:
I still think that meddling with the text interpreter is a big no-no >>>>> and an invitation to disaster.
Yes, S" 12.34e" >FLOAT is quite horrible, but having the behaviour of
"123.45" change depending on whether the floating point wordset is
loaded is also horrible. Probably best to leave things as they are, and >>>> maybe suggest a nonstandard extension to treat 123.45 as a float. To
get a double cell you'd use
Offically 123.45 is not a double number. It should end with a decimal point.
How is the support for a proposal:
Double numbers should start and end with a dot.
Now any numbers containing a single dot are automatically fp
A program that uses single dots to indicate doubles, should
declare an environmental dependancy. The default behaviour it
that they are floats.
In this way most programs that uses fp and use single dots are
fully compliant.
There are people who are font of 01/02/03 date (2003 januari 2 )
indications that are examples in Starting Forth.
You could do this with recognizers (I suppose).
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.
I have published yourforth, an altenative to jonesforth. It is 32 bits
and I have eliminated all double precision crap, contributing to
it pedagogical value.
Groetjes Albert
Although I can understand the technical, historical and pragmatic
reasons of Chuck for (a) signifying a double number by a dot and (b) the
inclusion of a double number recognizer in the text interpreter, I never
followed suit.
Double number support was NEVER part of the 4tH core - and frankly, the
initial idea was even to never support double numbers AT ALL. The
rationale behind that one was that integers at that time were 32bit
anyway - the identical precision that double numbers covered - so.. why?
The range of 64bit numbers covers just about everything under the sun,
so I agree fullheartedly with the idea that double numbers are close to
complete obsolescence. The last time I used triple numbers was when I
wrote several IBAN related utilities on a 32-bit platform. Which most
double number applications boils down to nowadays.
If you want to have a serious mature Forth (gforth, ciforth) Anton Ertl
has explained that you need to have double precisions support for
multi precision, cryptography, crc and the like.
That doesn't mean that you have to build number display around the
<# #S #> wordset.
But.. I've been around here for a while and I think given there are
still people using WORD and vanilla counted strings that the 22nd
century Forths will still support double numbers - resulting in 1024 bit
double numbers.
Users of ciforth discover that WORD is a loaded extension, and they get educated as soon as they complain about this.
Hans Bezemer
Groetjes Albert
If you want to have a serious mature Forth (gforth, ciforth) Anton Ertl
has explained that you need to have double precisions support for
multi precision, cryptography, crc and the like.
In practice, multi precision arithmetic would likely be written as asm >primitives.
author = {M. Anton Ertl},
title = {Multi-precision integer arithmetics},
Paul Rubin <no.email@nospam.invalid> writes:--
In practice, multi precision arithmetic would likely be written as asm >>primitives.
That's what GMP does, but only for certain operations, while other
code may be more efficient for combinations of these operations (e.g., three-input addition).
In the history of programming, we usually started out with assembly
language, but over time, that has given way to programming in
higher-level languages. In the case of multi-precision arithmetics,
the support from high-level languages has been:
1) Double-precision types such as uint128_t in C, allowing to express
double-precision arithmetics and mixed single/double-precision
addition and multiplication.
2) Double-precision (D+) and mixed single/double precision words (UM*
M*) in Forth (M+ is not quite there, UM+ would be helpful for
multi-precision).
3) Add-with-carry builtins (compiler-specific) and intrinsics
(architecture-specific) in C compilers.
4) Arbitrary-precision arithmetics in a number of higher-level
langyages. The size depends on the data, which results in boxing
and unboxing overhead, which makes that feature really slow in all
implementations I know. Also, in most languages the usual case is
single-precision, so the incentives for making the multi-precision
ase fast are small. It's just an insurance against overflow.
5) _Bitint() in C23. gcc-15.1 supports numbers up to 65,535 bits, and
clang-20.1 supports numbers up to 8,388,608bits. The code produced
for now is mediocre, but that can change.
I have compared assembly language, 1), 3), and 5) [ertl25-carry2].
One can get C compilers to produce quite good code with 1) and 3),
but, depending on the architecture, sometimes 1) is better, and
sometimes 3). Ideally the compilers should produce the optimal code
with 5), but for now, they don't.
As long as we do not add something like 5) to Forth, 2) (close to C's
1) is the way to go if we want to express this stuff in Forth. Not
everyone wants Forth to be able to express such things with ease and efficiency competetive with C (before _Bitint()), though.
- anton
@InProceedings{ertl25-carry2,
author = {M. Anton Ertl},
title = {Multi-precision integer arithmetics},
booktitle = {Tagungsband des Jahrestreffens 2025 der
GI-Fachgruppe ``Programmiersprachen und
Rechenkonzepte''},
year = {2025},
series = {INSIGHTS --- Schriftenreihe der Fakult\"at Technik},
pages = {15--25},
url = {https://www.complang.tuwien.ac.at/papers/ertl25-carry2.pdf},
slides-url = {https://www.complang.tuwien.ac.at/papers/ertl25-carry2-slides.pdf},
url-proceedings = {https://www.dhbw-stuttgart.de/fileadmin/dateien/Forschung/Forschungsschwerpunkte_Technik/DHBW_Stuttgart_INSIGHTS_1_2025_Tagungsband_Jahrestreffen_GI-Fachgruppe_Programmiersprachen_und_Rechenkonzepte_2025.pdf},
abstract = {Multi-precision integer arithmetics is widely used,
among other things in public-key cryptography and
when computing many digits of transcendental
numbers. The present paper discusses
multi-precision addition and multiplication:
architectural support and its use in hand-written
assembly language, libraries that use such
assembly-language code, and programming language
support and how close the code generated by Clang
and GCC is to the hand-written assembly language.}
}
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
author = {M. Anton Ertl},
title = {Multi-precision integer arithmetics},
This paper and the linked one about adding carry bits to the RISC-V
machine registers are interesting. Someone recently mentioned that the RISC-V vector extension has ADC so it might be worth evaluating that in future versions of the paper.
IDK if it's in the spirit of Forth to have anything like _Bitint() and
I'm surprised to hear about it in C (I didn't know about it before). I
doubt it but your judgment is better than mine on such questions.
I think variable sized bignum arithmetic like 4096 bits is fading out of public key cryptography these days, as algorithms like RSA are being
replaced by elliptic curve algorithms with fixed key sizes, typically
256 bits.
Paul Rubin <no.email@nospam.invalid> wrote:
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
author = {M. Anton Ertl},
title = {Multi-precision integer arithmetics},
This paper and the linked one about adding carry bits to the RISC-V
machine registers are interesting. Someone recently mentioned that the
RISC-V vector extension has ADC so it might be worth evaluating that in
future versions of the paper.
IDK if it's in the spirit of Forth to have anything like _Bitint() and
I'm surprised to hear about it in C (I didn't know about it before). I
doubt it but your judgment is better than mine on such questions.
I think variable sized bignum arithmetic like 4096 bits is fading out of
public key cryptography these days, as algorithms like RSA are being
replaced by elliptic curve algorithms with fixed key sizes, typically
256 bits.
Elliptic curve algorithms can use significanty smaller primes than
RSA, but IIUC 256 bits is deemed to be dangerously low.
--
Waldek Hebisch
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.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 18:04:49 |
| Calls: | 810 |
| Calls today: | 1 |
| Files: | 1,287 |
| D/L today: |
10 files (21,017K bytes) |
| Messages: | 193,396 |