Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #134562
| From | jkn <jkn+nin@nicorp.co.uk> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Recognizer proposal |
| Date | 2026-02-10 17:48 +0000 |
| Message-ID | <mv19avFqi4mU1@mid.individual.net> (permalink) |
| References | <2026Feb9.084944@mips.complang.tuwien.ac.at> <nnd$1c958fc8$24a55a72@293ae8f8b50e0c83> |
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
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web