Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #58812

Re: "Recognizing" a parser generator (and a compiler compiler)

Show all headers | View raw

On 5/8/2017 05:57, hughaguilar96@gmail.com wrote:
> On Sunday, May 7, 2017 at 7:29:33 PM UTC-7, Joel Rees wrote:
>> What am I missing, Alex?
>> 
>> I don't write lex and yacc (or flex and bison) in Forth because
>> they just get in the way.
> 
> Recognizers are a very bad idea. This is an effort to give Forth
> syntax --- but a fundamental feature of Forth is that it doesn't have
> syntax --- most people (including myself) got into Forth originally
> because it was easy to understand and straight-forward.

No, it's not an effort to give Forth "syntax". Have you read the 
proposal? It clearly says

    The Forth compiler can be extended easily. The Forth
    interpreter however has a fixed set of capabilities as outlined
    in section 3.4 of the standard text: Words from the dictionary
    and some numbers.

    It's not easily possible to use the Forth text interpreter in
    an application or system extension context. The building blocks
    (FIND, COMPILE,, >NUMBER etc) are available but there is a gap
    between them and what the Forth interpreter does. Applications
    need to use either additional system provided and system
    specific intermediate words (if available) or have to re-invent
    the wheel to use e.g. numbers with a sign or hex numbers with
    the $ prefix.

    Some Forth interpreters have ways to add new data types. That
    makes it possible to use a loadable library to implement new
    data types to be handled like the built-in ones. An example are
    the floating point numbers. They have their own parsing and
    data handling words including a stack of their own.

    To actually handle data in the Forth context, the processing
    actions need to be STATE aware. It would be nice if the Forth
    text interpreter, that maintains STATE, is able to do the data
    processing without exposing STATE to the data handling methods.
    For that the different methods need to be registered somehow.



> 
> Right now, the major problem with ANS-Forth is ambiguity, with every

That's a matter of opinion; you appear to be the only person claiming 
this. "Major" seems to be a bit over dramatic.

> ANS-Forth compiler (SwiftForth, VFX and gForth) being incompatible
> with each other. Recognizers are just more ambiguity. Lots of
> Forth-200x aspiring leaders will write recognizers in the hope that
> they will pick up some followers so they can honestly describe
> themselves as a leaders. 

Sigh. Unlike you, most folks here aren't engaged in dick measuring contests.

> All of these recognizers will clash with
> each other, so you get a balkanization of Forth-200x. Every program
> will have to declare a dependency as to which recognizers it requires
> to be installed for the program to work, so none of the programs will
> be compatible with each other. In many cases you may have the needed
> recognizers installed for your program to supposedly work, but your
> program will still not work because of the order that the recognizers
> were installed.

Complete bollox. This from a man that can't even handle a pointer.

> 
> The Forth-200x committee fail to understand the purpose of a standard
> --- portability of programs.
> 
> Alex McDonald has said on multiple occasions that he: "does standards
> for a living." He promotes recognizers because they are gratuitous
> complexity --- he hopes to get promoted to the Forth-200x committee
> --- his goal with recognizers is to prove to everybody that he is
> smarter than they are, or at least to confuse everybody, which is
> pretty much the same thing: "If you can't dazzle 'em with brilliance,
> then baffle 'em with bull!"
> 

Or write long meaningless posts on CLF. Seems to work for you.

-- 
Alex

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

"Recognizing" a parser generator (and a compiler compiler) Joel Rees <joel.rees@gmail.com> - 2017-05-07 19:29 -0700
  Re: "Recognizing" a parser generator (and a compiler compiler) hughaguilar96@gmail.com - 2017-05-07 21:57 -0700
    Re: "Recognizing" a parser generator (and a compiler compiler) Alex <alex@rivadpm.com> - 2017-05-08 09:55 +0100
  Re: "Recognizing" a parser generator (and a compiler compiler) Alex <alex@rivadpm.com> - 2017-05-08 09:41 +0100
    Re: "Recognizing" a parser generator (and a compiler compiler) Joel Rees <joel.rees@gmail.com> - 2017-05-08 21:07 -0700
      Re: "Recognizing" a parser generator (and a compiler compiler) Alex <alex@rivadpm.com> - 2017-05-09 07:50 +0100
        Re: "Recognizing" a parser generator (and a compiler compiler) "Elizabeth D. Rather" <erather@forth.com> - 2017-05-08 21:39 -1000
          Re: "Recognizing" a parser generator (and a compiler compiler) "HAA" <someone@microsoft.com> - 2017-05-10 15:27 +1000
            Re: "Recognizing" a parser generator (and a compiler compiler) Alex <alex@rivadpm.com> - 2017-05-10 08:21 +0100
              Re: "Recognizing" a parser generator (and a compiler compiler) "HAA" <someone@microsoft.com> - 2017-05-10 18:15 +1000
          Re: "Recognizing" a parser generator (and a compiler compiler) Joel Rees <joel.rees@gmail.com> - 2017-05-10 00:53 -0700
            Re: "Recognizing" a parser generator (and a compiler compiler) Alex <alex@rivadpm.com> - 2017-05-10 08:59 +0100
      Re: "Recognizing" a parser generator (and a compiler compiler) mhx@iae.nl - 2017-05-10 02:52 -0700
        Re: "Recognizing" a parser generator (and a compiler compiler) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 11:59 +0200
          Re: "Recognizing" a parser generator (and a compiler compiler) Joel Rees <joel.rees@gmail.com> - 2017-05-10 05:46 -0700
          Re: "Recognizing" a parser generator (and a compiler compiler) mhx@iae.nl - 2017-05-10 05:48 -0700

csiph-web