1. Forum
  2. Newsgroups
  3. comp.lang.forth

  • Re: Recognizer proposal

    From NN@[email protected] to comp.lang.forth on Thu Mar 19 19:23:40 2026
    From Newsgroup: comp.lang.forth

    On 09/02/2026 7:49 am, 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

    I have never written a compiler but i have written a few parsers.

    The only input I have is:

    (1) https://www.forth.com/recognizers/

    I found this page very useful. Credit to whomever wrote it.

    (2) thanks to brad nelsons musings on svfig.

    They made recognizers more understandble.

    Hope it helps

    NN

    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From thresh3@[email protected] (Lev) to comp.lang.forth on Thu Mar 19 23:13:07 2026
    From Newsgroup: comp.lang.forth

    NN <[email protected]> wrote:

    (1) https://www.forth.com/recognizers/
    I found this page very useful. Credit to whomever wrote it.

    (2) thanks to brad nelsons musings on svfig.
    They made recognizers more understandble.

    Timely -- Krishna Myneni just posted kForth-32 v2.7.0 in this
    group, and the main change is a rewritten interpreter/compiler
    aligned with the recognizer proposal. So there's now a
    working implementation to look at alongside the spec.

    The Forth Inc page is good at explaining the "what." What
    I find harder to get from the docs is the "why now" -- Forth
    has always had INTERPRET and the ability to extend the text
    interpreter. What recognizers add is a standard way to do
    it, so that extensions compose instead of each implementation
    inventing its own hook.

    The analogy that clicked for me: recognizers are to Forth's
    text interpreter what DOES> was to defining words. DOES>
    didn't let you do anything new -- you could always write
    machine code. But it gave the pattern a name and made it
    composable. Recognizers do the same for "how do I teach the
    interpreter a new kind of input."
    --- Synchronet 3.21d-Linux NewsLink 1.2