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

Groups > comp.compilers > #1849

Re: Parsing partial sentences

Show all headers | View raw

Am 11.04.2017 um 10:31 schrieb Hans-Peter Diettrich:

[John]
> Here's a thought that sometimes works: try parsing the #define text,
> if it succeeds store the parsed version, otherwise store the text.

How do you detect "succeeds", and what's the parser output in this case?

My LL parser fails with the first token, because it expects a C module,
so that there is no useful output available.

An LR parser instead could stop with something like
  goal-->expression-->addition-->(identifier="a", identifier="b").

Hmm, a similar result could be achieved with an LL top-down parser,
whose goal is composed of the expected (handled) non-terminals. This
would only require a modification to the parser for that goal, which
tries all alternatives in sequence and stops on the first successful
parse (NFA). Parsing has to be restarted at the begin of the text
snippet, after an alternative failed to parse. This part is covered in
LR bottom-up parsers by the NFA to DFA conversion.


> But be prepared for that to fail, e.g.:
>
> #define FOO a + b

When I'd try to convert that into a function body, the resulting
function could look like
   void FOO() { a + b; }
or
   int FOO() { return a + b; }
what are not valid C modules, so that FOO were flagged to be
not-a-function, and its further occurences have to be expanded as usual.

Only if the identifiers a and b have been declared or #defined before,
FOO() would become a valid function (above) or constant of a compatible
type, like
   const int FOO = a+b;

Instead
   #define FOO 0x12345
would parse into something like
   goal-->value-->literal="0x1235"
which could be translated into
   const int FOO=0x12345;

In this case some manual postprocessing could define an enum
   typedef enum SomeField = { FOO=0x1234, BAR=0, BAZ=42 };
which then could be used to assign a more specific type to strzct fields
or subroutine arguments.

DoDi

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

Thread

Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-03 09:57 +0200
  Re: Parsing partial sentences Fernando <pronesto@gmail.com> - 2017-04-04 06:05 -0700
    Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-07 11:16 -0400
      Re: Parsing partial sentences George Neuner <gneuner2@comcast.net> - 2017-04-07 12:59 -0400
        Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-07 22:24 +0200
          Re: Parsing partial sentences George Neuner <gneuner2@comcast.net> - 2017-04-10 20:22 -0400
            Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-11 10:31 +0200
              Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-11 19:40 +0200
              Re: Parsing partial sentences George Neuner <gneuner2@comcast.net> - 2017-04-11 23:05 -0400
                Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-12 13:45 +0200
          Re: Parsing partial sentences Martin Ward <martin@gkc.org.uk> - 2017-04-11 10:30 +0100
  Re: Parsing partial sentences Walter Banks <walter@bytecraft.com> - 2017-04-27 10:58 -0400
    Re: Parsing partial sentences Kaz Kylheku <686-678-9105@kylheku.com> - 2017-04-27 19:08 +0000
      Re: Parsing partial sentences rugxulo@gmail.com - 2017-04-28 16:32 -0700
      Re: Parsing partial sentences Marco van de Voort <marcov@toad.stack.nl> - 2017-04-29 14:57 +0000
        Re: Parsing partial sentences Kaz Kylheku <686-678-9105@kylheku.com> - 2017-04-30 16:31 +0000
    Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-28 02:48 +0200

csiph-web