Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #134574
| From | jkn <jkn+nin@nicorp.co.uk> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Recognizer proposal |
| Date | 2026-02-11 20:46 +0000 |
| Message-ID | <mv485qF9t6hU1@mid.individual.net> (permalink) |
| References | (1 earlier) <nnd$1c958fc8$24a55a72@293ae8f8b50e0c83> <mv19avFqi4mU1@mid.individual.net> <nnd$379fa837$3ffa5131@754aac6b211328ed> <mv3dbkF4u38U1@mid.individual.net> <nnd$65b4b0f6$3a20bb7c@a104114058553429> |
On 11/02/2026 14:59, Hans Bezemer wrote:
> On 11-02-2026 14:09, jkn wrote:
>> On 11/02/2026 12:54, Hans Bezemer wrote:
>>> On 10-02-2026 18:48, jkn wrote:
>>>> On 10/02/2026 12:36, Hans Bezemer wrote:
>>>>> On 09-02-2026 08:49, Anton Ertl wrote:
>>>>>> A more fleshed-out version of the current recognizer proposal is
>>>>>> online:
>>>>>> <https://forth-standard.org/proposals/recognizer-committee-
>>>>>> proposal-2025-09-11?hideDiff#reply-1614>
>>>>>>
>>>>>> After many years this proposal is in transition from being fluid to
>>>>>> solid, so if you want major upheavals, I doubt that your input
>>>>>> will be
>>>>>> acted upon (but you might still want to give it). 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...
>>
>>
>
> But have you ever programmed in Forth? I mean - every student can write
> a Forth compiler - and many do - but in my experience appreciating the
> elegance of the system comes with using it. Not building it.
>
> Like appreciation of an apple pie recipe comes with eating it, not
> baking it.
>
> Hans Bezemer
I wrote my Forth system in order to write an application, so yes, I have
programmed in Forth.
Have I fully groked "The Forth Way"? No, I indicate my position above.
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