4 ms·

Yes. This is the reason it is way easier to hand-build a parser for C than try to use any kind of parser generator.

by sedachv 12y ago

JoeAltmaier 12y ago
Bison and Flex work fine - do they count as 'parser generators'?
- sedachv 12y ago
  Flex does not work fine, that's why you need the lexer hack: https://en.wikipedia.org/wiki/The_lexer_hack https://en.wikipedia.org/wiki/The_lexer_hack Non-working (no lexer hack) Flex and Bison specification for C99: https://gist.github.com/codebrainz/2933703 https://gist.github.com/codebrainz/2933703 653 lines Hand-written recursive-descent C parser and pre-processor (something not handled by Lex/Yacc) that produces executable Common Lisp code: https://github.com/vsedach/Vacietis/blob/master/compiler/reader.lisp https://github.com/vsedach/Vacietis/blob/master/compiler/rea... 935 lines
  - JoeAltmaier 12y ago
    You can put whatever code you want into the Flex phrase rules. The 'lexer hack' can be implemented there. That's what I do whenever I have to parse something like C.
    - sedachv 12y ago
      Exactly. You have to drop hooks into the lexer from the parser, and by the time you're done you end up with just as much code. Only it's slower than a recursive-descent parser would be, and a lot of the time parsing speed really matters because it shows up as user-visible latency.
      - vidarh 12y ago
        While I have a strong dislike for lex/yacc and descendants, the "hooks" you need for C are trivial. As far as I remember the only thing you need is an ability for the lexer to check whether or not a given identifier is a variable or type. Even that is only needed if you want to report more specific information up to the parser. E.g. Clang doesn't. In Clang it is instead the parser that looks up the information in order to figure out what type of identifier it has received.
        JoeAltmaier 12y ago
        Right but by then the rule matching has been done - now you're writing code to distinguish rules instead of code to handle rules. The advantage of a parser tool is, it makes the language constructs explicit in the code - here be assignment, here be for() etc. That has some value.
        JoeAltmaier 12y ago
        And what are the alternatives? I've always wanted a parser object (in C++ anyway) that I can add constructions to, feed it scanner output and have it build a symbol table and semantic tree. Does such a thing exist?

Yes. This is the reason it is way easier to hand-build a parser for C than try to use any kind of parser generator.

by sedachv 12y ago

Yes. This is the reason it is way easier to hand-build a parser for C than try to use any kind of parser generator.

JoeAltmaier 12y ago

Bison and Flex work fine - do they count as 'parser generators'?

sedachv 12y ago
Flex does not work fine, that's why you need the lexer hack: https://en.wikipedia.org/wiki/The_lexer_hack https://en.wikipedia.org/wiki/The_lexer_hack Non-working (no lexer hack) Flex and Bison specification for C99: https://gist.github.com/codebrainz/2933703 https://gist.github.com/codebrainz/2933703 653 lines Hand-written recursive-descent C parser and pre-processor (something not handled by Lex/Yacc) that produces executable Common Lisp code: https://github.com/vsedach/Vacietis/blob/master/compiler/reader.lisp https://github.com/vsedach/Vacietis/blob/master/compiler/rea... 935 lines
- JoeAltmaier 12y ago
  You can put whatever code you want into the Flex phrase rules. The 'lexer hack' can be implemented there. That's what I do whenever I have to parse something like C.
  - sedachv 12y ago
    Exactly. You have to drop hooks into the lexer from the parser, and by the time you're done you end up with just as much code. Only it's slower than a recursive-descent parser would be, and a lot of the time parsing speed really matters because it shows up as user-visible latency.
    - vidarh 12y ago
      While I have a strong dislike for lex/yacc and descendants, the "hooks" you need for C are trivial. As far as I remember the only thing you need is an ability for the lexer to check whether or not a given identifier is a variable or type. Even that is only needed if you want to report more specific information up to the parser. E.g. Clang doesn't. In Clang it is instead the parser that looks up the information in order to figure out what type of identifier it has received.
      - JoeAltmaier 12y ago
        Right but by then the rule matching has been done - now you're writing code to distinguish rules instead of code to handle rules. The advantage of a parser tool is, it makes the language constructs explicit in the code - here be assignment, here be for() etc. That has some value.
      - JoeAltmaier 12y ago
        And what are the alternatives? I've always wanted a parser object (in C++ anyway) that I can add constructions to, feed it scanner output and have it build a symbol table and semantic tree. Does such a thing exist?