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. 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
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 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 <698fd57e$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote:
On 14/02/2026 10:50 am, Gerry Jackson wrote:
...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.
You have to test also the words you define yourself. The best is to
come up with complete test for each word, in combination with the specification and the definition.
This is an example from ciforth:
worddoc( {LOGIC},{0=},{zero_equals},{n --- ff},{ISO,FIG},
{Leave a true flag forthvar({ff}) is the number forthvar({n})
is equal to zero, otherwise leave a false flag.
It may be aliased to forthcode({NOT}) , which inverts a flag.
},{{=},{0<}},
{ {0 0= .},{_T_},
{ 1 0= .},{0},
{ -1 0= .},{0} },
enddoc)
CODE_HEADER({0=},{ZEQU}) dnl ZEQU is the name used in the assembler file.
POP AX _C{S2}
AND AX,AX
SETZ AL
MOVZX AX,AL
NEG AX
_PUSH
_C
Stack effect, properties, specifications, also's , tests and
code.
(Macro _PUSH has inside a _NEXT. )
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.
On 26 Feb 2026 at 05:25:12 CET, "Paul Rubin" <no.email@nospam.invalid> wrote:
Hans Bezemer <the.beez.speaks@gmail.com> writes:
It does seem to me that with 32-bit systems widespread, double ints have
gotten less important. I wouldn't want the standard behaviour to
change, but I'd probably use the nonstandard extension if it existed.
With the extension turned on, to get the double int, you'd use 12345 0
or maybe something like "D# 123 45" .
Double ints are maybe still useful on 8 bit systems with 16 bit cells.
We (Wodni & Pelc GmbH) have clients using a 32 bit host who depend
on 128 bit integers. They have in excess of 10,000 users of their >application.
Even if they converted to a 64 bit host Forth, they would still need
double numbers.
Stephen
We (Wodni & Pelc GmbH) have clients using a 32 bit host who depend
on 128 bit integers. They have in excess of 10,000 users of their
application.
I appreciate that you will not disclose much on your clients.
Can you reveal what kind of applications would use 128 bit integers
but not more precision?
On 26 Feb 2026 at 05:25:12 CET, "Paul Rubin" <no.email@nospam.invalid> wrote:
Hans Bezemer <the.beez.speaks@gmail.com> writes:
It does seem to me that with 32-bit systems widespread, double ints have
gotten less important. I wouldn't want the standard behaviour to
change, but I'd probably use the nonstandard extension if it existed.
With the extension turned on, to get the double int, you'd use 12345 0
or maybe something like "D# 123 45" .
Double ints are maybe still useful on 8 bit systems with 16 bit cells.
We (Wodni & Pelc GmbH) have clients using a 32 bit host who depend
on 128 bit integers. They have in excess of 10,000 users of their application.
Even if they converted to a 64 bit host Forth, they would still need
double numbers.
Stephen
Moreover the USA NSA pushes towards elliptic curves. Maybe they have
a backdoor. Otoh RSA 4096 is well established.
The application is construction planning. Sometimes over 10 currencies
are used. The app must allow for a total cost of well over 10 billion
dollars US. They tried 80 bit FP, but the difference in dollars given
by an 128 bit integer calculation (effectively a huge spreadsheet) and
an 80 bit floating point version was 10 million dollars for capping
the piles in the new Hong Kong airport.. There are many examples in construction of dealing with two quantities, one of which is large and
the other small. Capping piles is one of these.
Stephen Pelc <stephen@vfxforth.com> writes:
The application is construction planning. Sometimes over 10 currencies
are used. The app must allow for a total cost of well over 10 billion
dollars US. They tried 80 bit FP, but the difference in dollars given
by an 128 bit integer calculation (effectively a huge spreadsheet) and
an 80 bit floating point version was 10 million dollars for capping
the piles in the new Hong Kong airport.. There are many examples in
construction of dealing with two quantities, one of which is large and
the other small. Capping piles is one of these.
I wonder if this was due to some kind of numerical instability in which
case 128 bits might not be enough either. 80 bit FP has a 53 bit
mantissa and 2**53 pennies is 9e15 dollars. Did you try the same
calculation with say 256 bit FP, bignums, or whatever?
Stephen Pelc <stephen@vfxforth.com> writes:
The application is construction planning. Sometimes over 10 currencies
are used. The app must allow for a total cost of well over 10 billion
dollars US. They tried 80 bit FP, but the difference in dollars given
by an 128 bit integer calculation (effectively a huge spreadsheet) and
an 80 bit floating point version was 10 million dollars for capping
the piles in the new Hong Kong airport.. There are many examples in
construction of dealing with two quantities, one of which is large and
the other small. Capping piles is one of these.
I wonder if this was due to some kind of numerical instability in which
case 128 bits might not be enough either. 80 bit FP has a 53 bit
mantissa and 2**53 pennies is 9e15 dollars. Did you try the same
calculation with say 256 bit FP, bignums, or whatever?
On 3 Mar 2026 at 13:47:54 CET, "albert@spenarnc.xs4all.nl" <albert@spenarnc.xs4all.nl> wrote:
We (Wodni & Pelc GmbH) have clients using a 32 bit host who depend
on 128 bit integers. They have in excess of 10,000 users of their
application.
I appreciate that you will not disclose much on your clients.
Can you reveal what kind of applications would use 128 bit integers
but not more precision?
The application is construction planning. Sometimes over 10 currencies are used. The app must allow for a total cost of well over 10 billion dollars US. They tried 80 bit FP, but the difference in dollars given by an 128 bit integer calculation (effectively a huge spreadsheet) and an 80 bit floating point version was 10 million dollars for capping the piles in the new Hong Kong airport.. There are many examples in construction of dealing with two quantities, one of which is large and the other small. Capping piles is one of
these.
Stephen
On 2/21/26 9:40 AM, Anton Ertl wrote:
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.
My initial study of the recognizer proposal, and first steps to
implement it in kForth-64, have led to a few observations:
...
My inclination is to use C-style syntax for a long long literal for >REC-NUMBER to recognize a double length number e.g.
-170141183460469231731687303715884105728LL
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
My inclination is to use C-style syntax for a long long literal for >>REC-NUMBER to recognize a double length number e.g.
-170141183460469231731687303715884105728LL
My recommendation is to support the standard syntax
#-170141183460469231731687303715884105728.
Recent development Gforth has
.-is-dcell? ( - flag ) gforth-experimental "dot-is-dcell-question"
If this user flag is true (default), 'rec-number' recognizes numbers
without prefix that contain a decimal point as double-cell numbers.
Otherwise 'rec-number' does not recognize the number, and, if present,
'rec-float' will recognize it as a floating-point number.
'to .-is-dcell?' run-time: ( x - ) If x=0 change the value of
'.-is-dcell?' to false, otherwise to true.
I.e., by default "123." is recognized as double, but once you perform
false to .-is-dcell?
it will no longer be recognized as double, and rec-float will get a
chance at recognizing it (with the default recognizer order), and will >recognize it as float. And if you want to write a double, you write
"#123." or "$7b.".
- anton
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
My inclination is to use C-style syntax for a long long literal for
REC-NUMBER to recognize a double length number e.g.
-170141183460469231731687303715884105728LL
My recommendation is to support the standard syntax
#-170141183460469231731687303715884105728.
Recent development Gforth has
.-is-dcell? ( - flag ) gforth-experimental "dot-is-dcell-question"
If this user flag is true (default), 'rec-number' recognizes numbers
without prefix that contain a decimal point as double-cell numbers.
Otherwise 'rec-number' does not recognize the number, and, if present,
'rec-float' will recognize it as a floating-point number.
'to .-is-dcell?' run-time: ( x - ) If x=0 change the value of
'.-is-dcell?' to false, otherwise to true.
I.e., by default "123." is recognized as double, but once you perform
false to .-is-dcell?
it will no longer be recognized as double, and rec-float will get a
chance at recognizing it (with the default recognizer order), and will recognize it as float. And if you want to write a double, you write
"#123." or "$7b.".
- anton
In article <2026Mar9.084942@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
My recommendation is to support the standard syntax
#-170141183460469231731687303715884105728.
If the next step is to obsolete default BASE double numbers, I am all
for it.
Recent development Gforth has
.-is-dcell? ( - flag ) gforth-experimental "dot-is-dcell-question"
If this user flag is true (default), 'rec-number' recognizes numbers
without prefix that contain a decimal point as double-cell numbers.
Otherwise 'rec-number' does not recognize the number, and, if present,
'rec-float' will recognize it as a floating-point number.
'to .-is-dcell?' run-time: ( x - ) If x=0 change the value of
'.-is-dcell?' to false, otherwise to true.
I.e., by default "123." is recognized as double, but once you perform
false to .-is-dcell?
it will no longer be recognized as double, and rec-float will get a
chance at recognizing it (with the default recognizer order), and will >>recognize it as float. And if you want to write a double, you write >>"#123." or "$7b.".
Introducing another state besides STATE ?
(I tend to accept BASE as an internal state of the <# # #S #> class, rather >than a global state.)
albert@spenarnc.xs4all.nl writes:
In article <2026Mar9.084942@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
My recommendation is to support the standard syntax
#-170141183460469231731687303715884105728.
If the next step is to obsolete default BASE double numbers, I am all
for it.
Make a proposal. I doubt that it will find consensus, but I have been >surprised before.
- anton
On 3/9/26 2:49 AM, Anton Ertl wrote:
Krishna Myneni <krishna.myneni@ccreweb.org> writes:
My inclination is to use C-style syntax for a long long literal for
REC-NUMBER to recognize a double length number e.g.
-170141183460469231731687303715884105728LL
My recommendation is to support the standard syntax
#-170141183460469231731687303715884105728.
Recent development Gforth has
.-is-dcell? ( - flag ) gforth-experimental "dot-is-dcell-question"
If this user flag is true (default), 'rec-number' recognizes
numbers
without prefix that contain a decimal point as double-cell numbers.
Otherwise 'rec-number' does not recognize the number, and, if present, >> 'rec-float' will recognize it as a floating-point number.
'to .-is-dcell?' run-time: ( x - ) If x=0 change the value of
'.-is-dcell?' to false, otherwise to true.
I.e., by default "123." is recognized as double, but once you perform
false to .-is-dcell?
it will no longer be recognized as double, and rec-float will get a
chance at recognizing it (with the default recognizer order), and will
recognize it as float. And if you want to write a double, you write
"#123." or "$7b.".
- anton
I like the concept of requiring both the base prefix and the trailing decimal point -- this notation is far less likely to be confused for a floating point number than with the trailing decimal point alone.
In article <2026Mar10.083550@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
albert@spenarnc.xs4all.nl writes:
In article <2026Mar9.084942@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
My recommendation is to support the standard syntax
#-170141183460469231731687303715884105728.
If the next step is to obsolete default BASE double numbers, I am all
for it.
Make a proposal. I doubt that it will find consensus, but I have been
surprised before.
What do you think of this:
Decimal points are reserved for floating point, all else is obsolescent.
A double precision integer is recognized by
##-118189089000089082828282888888888828282828 $$FFFF0000FFFF0000FFFF0000FFFFF0000 %%111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
This is reminiscent of the LL suffix, but I like prefix better.
In a pinch you could do a portable implementation of
$$ FF0000FFFF0000FFFF0000FFFFF0000
to replace
$$FFFF0000FFFF0000FFFF0000FFFFF0000
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
(1) https://www.forth.com/recognizers/
I found this page very useful. Credit to whomever wrote it.
(2) thanks to brad nelsons musings on svfig.
They made recognizers more understandble.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,118 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 34:26:52 |
| Calls: | 14,340 |
| Files: | 186,357 |
| D/L today: |
12,254 files (3,846M bytes) |
| Messages: | 2,532,881 |