Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #134569
| From | jkn <jkn+nin@nicorp.co.uk> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Recognizer proposal |
| Date | 2026-02-11 13:09 +0000 |
| Message-ID | <mv3dbkF4u38U1@mid.individual.net> (permalink) |
| References | <2026Feb9.084944@mips.complang.tuwien.ac.at> <nnd$1c958fc8$24a55a72@293ae8f8b50e0c83> <mv19avFqi4mU1@mid.individual.net> <nnd$379fa837$3ffa5131@754aac6b211328ed> |
On 11/02/2026 12:54, Hans Bezemer wrote:
> On 10-02-2026 18:48, jkn wrote:
>> On 10/02/2026 12:36, Hans Bezemer wrote:
>>> On 09-02-2026 08:49, Anton Ertl wrote:
>>>> A more fleshed-out version of the current recognizer proposal is
>>>> online:
>>>> <https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11?hideDiff#reply-1614>
>>>>
>>>> After many years this proposal is in transition from being fluid to
>>>> solid, so if you want major upheavals, I doubt that your input will be
>>>> acted upon (but you might still want to give it). OTOH, if you find
>>>> any mistakes, missing parts or unclear parts, now is the time when
>>>> your input will be most effective. In either case, please report any
>>>> feedback by clicking on the Reply button on the web page above.
>>>>
>>>> - anton
>>>
>>>
>>> Although I'm not gonna honor this proposal - for architectual and
>>> technical reasons - I'd like to give my opinion anyway. Because this
>>> is a mistake of Forth-83 like proportions.
>>>
>>> But let's begin at the beginning: why is is this proposal needed?
>>> What should it fix?
>>>
>>> "The classical text interpreter is inflexible: E.g., adding
>>> floating-point recognizers requires hardcoding the change; several
>>> systems include system-specific hooks (sometimes more than one) for
>>> plugging in functionality at various places in the text interpreter."
>>>
>>> To begin with: this is incorrect. If I define this word:
>>>
>>> : f%
>>> bl word count >float 0= abort" Bad float"
>>> state @ if postpone fliteral then
>>> ; immediate
>>>
>>> Floating point numbers are recognized without a problem. So - the
>>> claim one needs to change the interpreter is simply false.
>>>
>>> Now what does TF have to say about "changing the interpreter"?
>>>
>>> "Don’t write your own interpreter/compiler when you can use Forth’s.
>>> Every time you see a unique interpreter, it implies that there is
>>> something particularly awkward about the problem. And that is almost
>>> never the case."
>>>
>>> Which is the case here as well. You can easily extend the language
>>> without changing the interpreter.
>>>
>>> "If you write your own interpreter, the interpreter is almost
>>> certainly the most
>>> complex, elaborate part of your entire application. You have switched
>>> from
>>> solving a problem to writing an interpreter."
>>>
>>> It is obvious you needs LOTS of code to make this work. Simply
>>> because it doesn't come with any type information. It's clear that
>>> "F%" carries an implicit type. But a recognizer needs code to
>>> recognize the type it is supposed to convert. You may it is trivial,
>>> but it is code nontheless. Code that has to be designed, implemented,
>>> tested and maintained. Such code is not required with "F%".
>>>
>>> Or - as TF puts it - "To simplify, take advantage of what’s available."
>>>
>>> Let's delve in a little deeper: "The difficulty of adding to the text
>>> interpreter may also have led to missed opportunities: E.g., for
>>> string literals the standard did not task the text interpreter with
>>> recognizing them, but instead introduced S" and S\" (and their
>>> complicated definition with interpretation and compilation semantics)."
>>>
>>> This is simply not true - and a disingenuous argument at best. Let's
>>> take another, related example:
>>>
>>> : .( [char] ) parse type ; immediate
>>>
>>> There is very little complexity here. So, the complexity is not in
>>> the PARSING of this word. The complexity lies in the (temporary)
>>> allocation of this word - and the lack of an interpreted version like
>>> "S(" - which would virtually completely eliminate "their complicated
>>> definition with interpretation and compilation semantics."
>>>
>>> In other words, the complexity doesn't lie within the problem itself,
>>> but in the atrocious design of the S" word - which had to be patched
>>> later on in order to function for the FILE wordset.
>>>
>>> Finally, in how far does this proposal fix the aforementioned
>>> problems of S"? It will still have to be allocated somewhere - and I
>>> don't see how it will alleviate "their complicated definition with
>>> interpretation and compilation semantics." They will only get worse,
>>> because one will have to add the recognition code.. Duh!
>>>
>>> Let's finish with some TF advise: "Anticipate things-that-may-change
>>> by organizing information, NOT by adding complexity. Add complexity
>>> only as necessary to make the current iteration work."
>>>
>>> It may be clear that this proposal only ADDS complexity. It doesn't
>>> alleviate the problem AT ALL. It makes it worse. Much worse. The only
>>> thing it does is add some "syntactic sugar" to those C programmers
>>> that couldn't live without locals.
>>>
>>> Now - you wan't hear me say that there wasn't some history here.
>>> Chuck should have refrained from adding double numbers to the
>>> interpreter. "D%" would have been fine. And sure - I can understand a
>>> dot in a number is a great self-documenting way to add "fractions" to
>>> fixed point number calculations.
>>>
>>> But from an architectural viewpoint, it is WRONG. Because it's a
>>> slippery slope as complex numbers, floating point numbers (IEEE,
>>> single precision, double precision - yeah, they come in different
>>> tastes) have proven. Single numbers - I get that. Forth would be
>>> awkward to work with when you need a thing like "S%" every single line.
>>>
>>> But this.. This is not the way to go.
>>>
>>> Hans Bezemer
>>
>> I have no skin in this game at all - I am basically an observer of
>> both the language, and this newsgroup. But it seems strange to me that
>> in a language that is so self-describedly flexible as Forth, the
>> operation of the inner interpreter should not itself be open to
>> flexibility.
>>
>> J^n
>>
>
> Maybe because you have no idea how this thing works.
Somewhat cheeky; I have at least written a Forth myself, even it was
some 35 years ago...
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