Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #134559 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2026-02-09 07:49 +0000 |
| Last post | 2026-03-19 23:13 +0000 |
| Articles | 20 on this page of 97 — 14 participants |
Back to article view | Back to comp.lang.forth
Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-09 07:49 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-10 13:36 +0100
Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-10 17:48 +0000
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-11 11:21 +1100
Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 09:05 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-11 12:46 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 13:36 +0100
Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 20:49 +0000
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-11 18:37 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 12:25 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 14:34 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-12 11:35 +1100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 07:24 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 10:59 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 10:13 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:22 +0100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:07 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-12 20:59 +1100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 12:35 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:30 +0100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:44 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 07:35 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 10:55 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-13 08:27 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 13:43 +0100
Re: Recognizer proposal Gerry Jackson <do-not-use@swldwa.uk> - 2026-02-13 23:50 +0000
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-14 12:53 +1100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-15 13:33 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-16 12:18 +1100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-19 13:42 +0100
Evolution of Forths was Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-19 14:38 +0100
Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-20 12:33 +1100
Re: Evolution of Forths was Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-20 11:58 +0100
Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-24 10:45 +1100
Re: Evolution of Forths was Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-21 16:35 +0100
Re: Evolution of Forths was Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-24 13:13 +1100
Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-02-25 20:25 -0800
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-26 06:53 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-26 13:09 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-27 20:24 +1100
Re: Recognizer proposal Gerry Jackson <do-not-use@swldwa.uk> - 2026-02-27 09:25 +0000
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-27 14:48 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-27 19:21 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-28 10:15 +1100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-28 15:34 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-28 17:56 +0100
Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-02-28 22:45 -0800
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-01 07:54 +0000
Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-01 14:17 -0800
Re: Recognizer proposal antispam@fricas.org (Waldek Hebisch) - 2026-03-02 00:21 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-02 12:36 +0100
Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-04 16:48 -0800
Re: Recognizer proposal antispam@fricas.org (Waldek Hebisch) - 2026-03-02 00:17 +0000
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-26 07:32 -0600
Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-02 13:23 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-03 13:47 +0100
Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-03 14:39 +0000
Re: Recognizer proposal Paul Rubin <no.email@nospam.invalid> - 2026-03-04 16:52 -0800
Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-03-06 10:54 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-06 12:22 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-03-07 17:58 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-03-03 18:33 +0100
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 13:54 +0100
Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 13:09 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-11 15:59 +0100
Re: Recognizer proposal jkn <jkn+nin@nicorp.co.uk> - 2026-02-11 20:46 +0000
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-11 16:30 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-12 12:07 +0100
Re: Recognizer proposal Lars Brinkhoff <lars.spam@nocrew.org> - 2026-02-12 13:00 +0000
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-12 12:55 +0000
Re: Recognizer proposal Hans Bezemer <the.beez.speaks@gmail.com> - 2026-02-13 14:17 +0100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-13 13:28 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-14 01:23 +1100
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-16 22:07 -0600
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-17 21:25 +1100
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-17 08:16 -0600
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:32 +0000
Re: Recognizer proposal Stephen Pelc <stephen@vfxforth.com> - 2026-02-17 14:13 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-17 20:21 +0100
Re: Recognizer proposal dxf <dxforth@gmail.com> - 2026-02-18 13:08 +1100
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-11 12:29 +0100
Re: Recognizer proposal minforth <minforth@gmx.net> - 2026-02-18 11:14 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:40 +0000
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-02-24 02:43 -0600
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-08 18:15 -0500
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-09 07:49 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-09 10:37 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-10 07:35 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-03-10 12:06 +0100
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-11 09:48 -0500
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-09 16:48 -0500
Re: Recognizer proposal Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-11 09:45 -0500
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-18 12:33 +0100
Re: Recognizer proposal anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-02-21 15:48 +0000
Re: Recognizer proposal albert@spenarnc.xs4all.nl - 2026-02-25 14:11 +0100
Re: Recognizer proposal NN <november.nihal@gmail.com> - 2026-03-19 19:23 +0000
Re: Recognizer proposal thresh3@fastmail.com (Lev) - 2026-03-19 23:13 +0000
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-02-09 07:49 +0000 |
| Subject | Recognizer proposal |
| Message-ID | <2026Feb9.084944@mips.complang.tuwien.ac.at> |
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
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-02-10 13:36 +0100 |
| Message-ID | <nnd$1c958fc8$24a55a72@293ae8f8b50e0c83> |
| In reply to | #134559 |
On 09-02-2026 08:49, Anton Ertl wrote:
> A more fleshed-out version of the current recognizer proposal is
> online:
> <https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11?hideDiff#reply-1614>
>
> After many years this proposal is in transition from being fluid to
> solid, so if you want major upheavals, I doubt that your input will be
> acted upon (but you might still want to give it). OTOH, if you find
> any mistakes, missing parts or unclear parts, now is the time when
> your input will be most effective. In either case, please report any
> feedback by clicking on the Reply button on the web page above.
>
> - anton
Although I'm not gonna honor this proposal - for architectual and
technical reasons - I'd like to give my opinion anyway. Because this is
a mistake of Forth-83 like proportions.
But let's begin at the beginning: why is is this proposal needed? What
should it fix?
"The classical text interpreter is inflexible: E.g., adding
floating-point recognizers requires hardcoding the change; several
systems include system-specific hooks (sometimes more than one) for
plugging in functionality at various places in the text interpreter."
To begin with: this is incorrect. If I define this word:
: f%
bl word count >float 0= abort" Bad float"
state @ if postpone fliteral then
; immediate
Floating point numbers are recognized without a problem. So - the claim
one needs to change the interpreter is simply false.
Now what does TF have to say about "changing the interpreter"?
"Don’t write your own interpreter/compiler when you can use Forth’s.
Every time you see a unique interpreter, it implies that there is
something particularly awkward about the problem. And that is almost
never the case."
Which is the case here as well. You can easily extend the language
without changing the interpreter.
"If you write your own interpreter, the interpreter is almost certainly
the most
complex, elaborate part of your entire application. You have switched from
solving a problem to writing an interpreter."
It is obvious you needs LOTS of code to make this work. Simply because
it doesn't come with any type information. It's clear that "F%" carries
an implicit type. But a recognizer needs code to recognize the type it
is supposed to convert. You may it is trivial, but it is code
nontheless. Code that has to be designed, implemented, tested and
maintained. Such code is not required with "F%".
Or - as TF puts it - "To simplify, take advantage of what’s available."
Let's delve in a little deeper: "The difficulty of adding to the text
interpreter may also have led to missed opportunities: E.g., for string
literals the standard did not task the text interpreter with recognizing
them, but instead introduced S" and S\" (and their complicated
definition with interpretation and compilation semantics)."
This is simply not true - and a disingenuous argument at best. Let's
take another, related example:
: .( [char] ) parse type ; immediate
There is very little complexity here. So, the complexity is not in the
PARSING of this word. The complexity lies in the (temporary) allocation
of this word - and the lack of an interpreted version like "S(" - which
would virtually completely eliminate "their complicated definition with
interpretation and compilation semantics."
In other words, the complexity doesn't lie within the problem itself,
but in the atrocious design of the S" word - which had to be patched
later on in order to function for the FILE wordset.
Finally, in how far does this proposal fix the aforementioned problems
of S"? It will still have to be allocated somewhere - and I don't see
how it will alleviate "their complicated definition with interpretation
and compilation semantics." They will only get worse, because one will
have to add the recognition code.. Duh!
Let's finish with some TF advise: "Anticipate things-that-may-change by
organizing information, NOT by adding complexity. Add complexity only as
necessary to make the current iteration work."
It may be clear that this proposal only ADDS complexity. It doesn't
alleviate the problem AT ALL. It makes it worse. Much worse. The only
thing it does is add some "syntactic sugar" to those C programmers that
couldn't live without locals.
Now - you wan't hear me say that there wasn't some history here. Chuck
should have refrained from adding double numbers to the interpreter.
"D%" would have been fine. And sure - I can understand a dot in a number
is a great self-documenting way to add "fractions" to fixed point number
calculations.
But from an architectural viewpoint, it is WRONG. Because it's a
slippery slope as complex numbers, floating point numbers (IEEE, single
precision, double precision - yeah, they come in different tastes) have
proven. Single numbers - I get that. Forth would be awkward to work with
when you need a thing like "S%" every single line.
But this.. This is not the way to go.
Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | jkn <jkn+nin@nicorp.co.uk> |
|---|---|
| Date | 2026-02-10 17:48 +0000 |
| Message-ID | <mv19avFqi4mU1@mid.individual.net> |
| In reply to | #134561 |
On 10/02/2026 12:36, Hans Bezemer wrote:
> On 09-02-2026 08:49, Anton Ertl wrote:
>> A more fleshed-out version of the current recognizer proposal is
>> online:
>> <https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11?hideDiff#reply-1614>
>>
>> After many years this proposal is in transition from being fluid to
>> solid, so if you want major upheavals, I doubt that your input will be
>> acted upon (but you might still want to give it). OTOH, if you find
>> any mistakes, missing parts or unclear parts, now is the time when
>> your input will be most effective. In either case, please report any
>> feedback by clicking on the Reply button on the web page above.
>>
>> - anton
>
>
> Although I'm not gonna honor this proposal - for architectual and
> technical reasons - I'd like to give my opinion anyway. Because this is
> a mistake of Forth-83 like proportions.
>
> But let's begin at the beginning: why is is this proposal needed? What
> should it fix?
>
> "The classical text interpreter is inflexible: E.g., adding
> floating-point recognizers requires hardcoding the change; several
> systems include system-specific hooks (sometimes more than one) for
> plugging in functionality at various places in the text interpreter."
>
> To begin with: this is incorrect. If I define this word:
>
> : f%
> bl word count >float 0= abort" Bad float"
> state @ if postpone fliteral then
> ; immediate
>
> Floating point numbers are recognized without a problem. So - the claim
> one needs to change the interpreter is simply false.
>
> Now what does TF have to say about "changing the interpreter"?
>
> "Don’t write your own interpreter/compiler when you can use Forth’s.
> Every time you see a unique interpreter, it implies that there is
> something particularly awkward about the problem. And that is almost
> never the case."
>
> Which is the case here as well. You can easily extend the language
> without changing the interpreter.
>
> "If you write your own interpreter, the interpreter is almost certainly
> the most
> complex, elaborate part of your entire application. You have switched from
> solving a problem to writing an interpreter."
>
> It is obvious you needs LOTS of code to make this work. Simply because
> it doesn't come with any type information. It's clear that "F%" carries
> an implicit type. But a recognizer needs code to recognize the type it
> is supposed to convert. You may it is trivial, but it is code
> nontheless. Code that has to be designed, implemented, tested and
> maintained. Such code is not required with "F%".
>
> Or - as TF puts it - "To simplify, take advantage of what’s available."
>
> Let's delve in a little deeper: "The difficulty of adding to the text
> interpreter may also have led to missed opportunities: E.g., for string
> literals the standard did not task the text interpreter with recognizing
> them, but instead introduced S" and S\" (and their complicated
> definition with interpretation and compilation semantics)."
>
> This is simply not true - and a disingenuous argument at best. Let's
> take another, related example:
>
> : .( [char] ) parse type ; immediate
>
> There is very little complexity here. So, the complexity is not in the
> PARSING of this word. The complexity lies in the (temporary) allocation
> of this word - and the lack of an interpreted version like "S(" - which
> would virtually completely eliminate "their complicated definition with
> interpretation and compilation semantics."
>
> In other words, the complexity doesn't lie within the problem itself,
> but in the atrocious design of the S" word - which had to be patched
> later on in order to function for the FILE wordset.
>
> Finally, in how far does this proposal fix the aforementioned problems
> of S"? It will still have to be allocated somewhere - and I don't see
> how it will alleviate "their complicated definition with interpretation
> and compilation semantics." They will only get worse, because one will
> have to add the recognition code.. Duh!
>
> Let's finish with some TF advise: "Anticipate things-that-may-change by
> organizing information, NOT by adding complexity. Add complexity only as
> necessary to make the current iteration work."
>
> It may be clear that this proposal only ADDS complexity. It doesn't
> alleviate the problem AT ALL. It makes it worse. Much worse. The only
> thing it does is add some "syntactic sugar" to those C programmers that
> couldn't live without locals.
>
> Now - you wan't hear me say that there wasn't some history here. Chuck
> should have refrained from adding double numbers to the interpreter.
> "D%" would have been fine. And sure - I can understand a dot in a number
> is a great self-documenting way to add "fractions" to fixed point number
> calculations.
>
> But from an architectural viewpoint, it is WRONG. Because it's a
> slippery slope as complex numbers, floating point numbers (IEEE, single
> precision, double precision - yeah, they come in different tastes) have
> proven. Single numbers - I get that. Forth would be awkward to work with
> when you need a thing like "S%" every single line.
>
> But this.. This is not the way to go.
>
> Hans Bezemer
I have no skin in this game at all - I am basically an observer of both
the language, and this newsgroup. But it seems strange to me that in a
language that is so self-describedly flexible as Forth, the operation of
the inner interpreter should not itself be open to flexibility.
J^n
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-02-11 11:21 +1100 |
| Message-ID | <698bcb8b$1@news.ausics.net> |
| In reply to | #134562 |
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.
[toc] | [prev] | [next] | [standalone]
| From | jkn <jkn+nin@nicorp.co.uk> |
|---|---|
| Date | 2026-02-11 09:05 +0000 |
| Message-ID | <mv2v1vFqfu2U1@mid.individual.net> |
| In reply to | #134563 |
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...
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-02-11 12:46 +0100 |
| Message-ID | <nnd$6c2097d2$07f89dac@189eb96a80bd6cc7> |
| In reply to | #134564 |
In article <mv2v1vFqfu2U1@mid.individual.net>, jkn <jkn+nin@nicorp.co.uk> 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. 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... > PREFIX addresses the problem that holding to the dogma about space delimiters present. In ciforth " handles any situation : ..... "########################## ..................... including `` " a " '' which is a 3 letter string. " is just a word that sits in the basic wordlist, subject to regular search rules, e.g. observing wordlists search order. It is found irrespective of spaces in the #. The #-definition could be changed, omitted, hidden whatever. It can be overwritten as usual, put in a wordlist etc. Hiding " doesn't prevent S" to work. Totally separate from whatever other prefixes you may define. Groetjes Albert -- The Chinese government is satisfied with its military superiority over USA. The next 5 year plan has as primary goal to advance life expectancy over 80 years, like Western Europe.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-02-11 13:36 +0100 |
| Message-ID | <nnd$6697318a$1bc526dc@ff3ef15f121536ce> |
| In reply to | #134564 |
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. 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... > 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
[toc] | [prev] | [next] | [standalone]
| From | jkn <jkn+nin@nicorp.co.uk> |
|---|---|
| Date | 2026-02-11 20:49 +0000 |
| Message-ID | <mv48ajF9t6hU2@mid.individual.net> |
| In reply to | #134567 |
On 11/02/2026 12:36, Hans Bezemer wrote: > 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. 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... >> > > 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. I was basing my comment from the wording of the proposal Anton linked to: """ The recognizer proposal is a factorization of the central part of the text interpreter. As before the text interpreter parses a white-space-delimited string. ... """ > > 4tH has a word called OMIT which only skips leading delimiters without > parsing anything. > > Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-02-11 18:37 +0000 |
| Message-ID | <2026Feb11.193710@mips.complang.tuwien.ac.at> |
| In reply to | #134564 |
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
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-02-13 12:25 +0100 |
| Message-ID | <nnd$60f6d6ba$29e14185@e7bc2a087c2ae26b> |
| In reply to | #134573 |
In article <2026Feb11.193710@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>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.
I consider it a design error that word / parse are obliged
to consume the end delimiter. Especially in view that parsing always
skips leading delimiters. This makes both unusable as factor for the
forth engine. This was a cute idea in the 70's where space delimiting
17 12 GCD 1001 LCM
was all the rage, before strings were invented.
BASIC beats Forth in this respect.
Combined with PREFIXes this change can dramatically simplify Forth.
There is no need to chop the input in pieces.
Kill the guy with the moustache! (from starting Forth).
If you lookup DROP<white space> this doesn't match DROP-FLOAT.
If DROP is a prefix. You have certainly a match.
It matches glossary "DR" also, but you accept it only if the "DR"
is a prefix. Else you discard it because in the input stream DR is not followed
by white space. These exceptions are processed afterwards.
What remains is a pointer in the input stream, much like normal
languages. This diminishes stack depth where it is mostly needed.
My FOUND uses (FIND) that in turn uses ~MATCH.
In the ciforth model I can add a one-screen addition, vectoring TOKEN
to NAME. Now you can parse lisp and pascal without changing the soul
of the parsing part of Forth.
I have demonstrated it with the gnu lisp interpreter. A large part
was a parser that distracts from the lisp goal,
leaving the impression that Forth is an awkward language.
>
>- anton
Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-02-11 14:34 +0100 |
| Message-ID | <nnd$4b4385df$6fc207a6@bc51f1c3df4eeea6> |
| In reply to | #134563 |
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. 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. > 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!) Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-02-12 11:35 +1100 |
| Message-ID | <698d205a$1@news.ausics.net> |
| In reply to | #134570 |
On 12/02/2026 12:34 am, Hans Bezemer wrote:
> 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. 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.
>>
>
> 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 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 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.
What the eyes don't see, the heart doesn't grieve.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-02-12 07:24 +0000 |
| Message-ID | <2026Feb12.082414@mips.complang.tuwien.ac.at> |
| In reply to | #134576 |
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
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-02-12 10:59 +0100 |
| Message-ID | <nnd$3eff7379$1c810e7c@faf68284076bf848> |
| In reply to | #134577 |
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
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-02-12 10:13 +0000 |
| Message-ID | <2026Feb12.111342@mips.complang.tuwien.ac.at> |
| In reply to | #134580 |
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
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-02-13 13:22 +0100 |
| Message-ID | <nnd$530b157d$6a7af6fa@2f0538f65d45a5d8> |
| In reply to | #134582 |
On 12-02-2026 11:13, Anton Ertl wrote: > 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 Frankly, you find the same kind of setup in 4tH's "interprt.4th" library routine: \ Define ABORT routine, simply print offending word defer NotFound :noname type [char] ? emit space ; is NotFound However, this one is used to define custom interpreters - not to define a REPL as front end for the language. It doesn't compile anything either. Usually "NotFound" is used to define custom error handling. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-02-13 13:07 +0100 |
| Message-ID | <nnd$20896ba2$51079f20@a224f9451dfeba87> |
| In reply to | #134580 |
In article <nnd$3eff7379$1c810e7c@faf68284076bf848>, Hans Bezemer <the.beez.speaks@gmail.com> wrote: >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). In the context of loadable "recognizers" ( PREFIX ) \--------------------8< linafp.frt -------- WANT -fp- : Doit QUIT ; \--------------------8<---------------------- # lina -c linafp.frt # linafp If you want linafp more to behave like a normal ciforth (automatically processing options), you can add : ' OPTIONS RESTORED ' ERROR RESTORED (A compiled program doesn't return to QUIT , all errors must be explicitly caught . Moreover the parsing of options must be explicitly invoked.) So there is no good reason to burden the \--------------------8<---------------------- : ascii 1 ARG[] DROP C@ . ; \--------------------8<---------------------- # lina -c ascii.frt # ascii A # 65 with a full fp packet and an assembler. Groetjes Albert > >Hans Bezemer -- The Chinese government is satisfied with its military superiority over USA. The next 5 year plan has as primary goal to advance life expectancy over 80 years, like Western Europe.
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-02-12 20:59 +1100 |
| Message-ID | <698da48b$1@news.ausics.net> |
| In reply to | #134577 |
On 12/02/2026 6:24 pm, 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. Yep. VFX supported three different f/p packs and SwiftForth's single (Win) f/p pack came with a variety of options. This was flexibility at the cost of the user knowing what he wanted. Users could save their choice to a new exe and have it available at bootup (though maybe not on the demo versions). > SwiftForth 4.x and VFX 5.x include the FP wordset by > default. These offer less options. VFX theoretically allows replacing the default pack with another but I had issues doing it on Win which I reported. I've not seen a fix/update for VFX for two years. SwiftForth f/p was rationalized down to one mode - 80 bits, hardware stack. As this made it possible to distribute my superior, VFX compatible, f/p output pack, I'm not complaining ;-) https://drive.google.com/file/d/1G8PYkEY73XPSygKlsWnM0XdZMx8ha7gb/view > Gforth, iForth, and lxf included the FP wordset by default in all > versions that I have tested. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-02-13 12:35 +0100 |
| Message-ID | <nnd$1c63eb87$7fa1bda9@e7c7f34cb53d548f> |
| In reply to | #134576 |
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: >>> 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. >>> >> >> 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 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 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. >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 -- The Chinese government is satisfied with its military superiority over USA. The next 5 year plan has as primary goal to advance life expectancy over 80 years, like Western Europe.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-02-13 13:30 +0100 |
| Message-ID | <nnd$11632ec1$4065bb35@f854684003bd1681> |
| In reply to | #134588 |
On 13-02-2026 12:35, albert@spenarnc.xs4all.nl wrote: > 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: >>>> 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. >>>> >>> >>> 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 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 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. >> 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
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web