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

Groups > comp.lang.forth > #58875

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

Show all headers | View raw

On 5/9/2017 05:07, Joel Rees wrote:
> On Monday, May 8, 2017 at 5:41:30 PM UTC+9, Alex wrote:
>> On 5/8/2017 03:29, Joel Rees wrote:
>>> What am I missing, Alex?
>> 
>> Am I the Alex you're asking? I'm sorry, I don't have any context
>> for this question.
> 
> :)
> 
> Sorry. This does seem to have been out-of-the-blue.
> 
>>> I don't write lex and yacc (or flex and bison) in Forth because
>>> they just get in the way.
>> 
>> But guessing, I suspect you might be over-reading into the
>> recognizer proposal the word "parse".
> 
> Or the word, "recognizer".
> 
>> In Forth, this does not mean a traditional parse, but simply
>> identifying a white space delimited word.
> 
> In your Forth, you mean.

No, in all Forths. If you look at the standard, it makes it clear that 
the only elements that are inspected character by character are words 
(whitespace delimited) that may be interpreted as numbers.

> 
> But don't we have access to regular expressions?

No. Unless you use a library, it's not part of standard Forth.

> 
> And, since space is the only delimiter Forth actually recognizes (not
> exaggerating much, here), is it wise to try to add such an override
> to the basic language?

We're not. A recognizer is invoked on whitespace delimited word boundaries.

> 
>>> I have <BUILDS, I mean, CREATE DOES>
>>> 
>>> (Which I was struggling with over the weekend, but that's
>>> another story not worth posting about.)
>>> 
>>> Each word in Forth defines its own syntax. Each word in Forth has
>>> its own attached semantics.
>> 
>> That's not strictly true. Words like IF pass semantic clues to
>> their corresponding ELSE THEN on the stack.
> 
> No, it is true. ELSE and THEN are syntactically and semantically
> parts of IF. You haven't properly parsed your IF until you've parsed
> the optional ELSE and the trailing THEN.

We're going to have to disagree. They have compile-time semantics that 
are different from their run-time semantics for one.

> 
> The fact that we use further words (sub-words? not really) in
> parsing a word does not mean that each of the words in use does not
> have its own syntax and semantics.

That contradicts what you said above?

> 
>>> A Forth program is explicitly a language.
>>> 
>>> Or am I way out in left field?
>>> 
>>> I think, if I were required to write formally provable Forth,
>>> I'd prefer to use provable CPU and restrict myself to a provable
>>> basic vocabulary, and build from there. (Hasn't this been done at
>>> least once?)
>> 
>> I'm not sure where this came from.
> 
> Well, I see I was somewhat out in left field on your proposal. But I
> think not very far.
> 
> Have you ever used lex and yacc? Or even worked on a program that is
> constructed using them?

No, although I have written a burg. (Forth doesn't have a requirement 
for either lex or yacc.)

-- 
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