5 ms·

I disagree that there's something wrong with writing your own parser. A simple recursive descent parser is very easy to write, and more importantly is very easy

I disagree that there's something wrong with writing your own parser. A simple recursive descent parser is very easy to write, and more importantly is very easy for someone else to understand. It does not require any esoteric knowledge of lookup tables and "advanced" parsing algorithms. I far prefer a stack trace from inside someone's hand-written recursive descent parser to the cryptic mess you get from Yacc or Antlr generated code. I also prefer not having to have a whole code generation stage in my build process just to support some small DSL I have embedded. This whole "you should never write your own parser" thing is so often parroted out as "wisdom"... But I honestly believe that most of the people that say this don't realise how easy it is to "roll your own".

Locke1689 14y ago
The pedagogical value of writing a parser for your compiler for any language more complex than, say, Scheme, is basically zero. Skip the parser, learn the useful stuff.
- eru 14y ago
  Oh, writing parsers is useful outside of writing compilers. But yes, you shouldn't be writing parsers in low level languages like C++. Write them in OCaml or Haskell. It's a joy there.
  - helmut_hed 14y ago
    This is my cue to mention Spirit http://boost-spirit.com/home/ http://boost-spirit.com/home/
- bane 14y ago
  unless you ever need to process data in a format for which a decent library doesn't already exist
  - wglb 14y ago
    Do you have an example in mind of such data?
    - helmut_hed 14y ago
      New file formats of all kinds are invented every day, often with some proprietary tool attached. Writing your own parser allows you to add value and/or interoperate with the proprietary system. Even in the cases where an open source parser already exists it may have performance issues, or not support the latest version of the format. Being able to roll your own in those cases is empowering. Of course you asked for examples... let me give that a try: 1) data from your favorite application that's been end-of-lifed and you're thinking of replacing with a competitor's tool 2) data from a later version of your favorite application that you want to use with an earlier version, because you don't want to upgrade 3) configuration information from some part of your IT infrastructure that you need to refer to as you restructure and upgrade 4) a big config file for some software, that contains an error somewhere and "grep" won't find it. Maybe it's a semantic error, for example. 5) a config file for some ancient crufty software you're replacing, but the config file is huge and contains a lot of institutional knowledge, so you want to automatically translate it to the new system's setup. Being able to generate even simple parsers gives you a lot of power. It's not as uncommon as you might imagine.
      - wglb 14y ago
        Having been in the business of reversing data formats in two different real-world contexts, I feel comfortable in saying that just about the last thing I would do is write a parser. One context was building a system to pull live financial data feeds. The other is in the software security business. In the former, often CSVs were what you would get, or fielded data. We built an engine that could easily inhale these. Including the bloomberg feed which was unusually complex. In the security business, one is often asked to assess some not-very-well specified protocol, or some protocol for which there is no documentation. So to deal with it you 1) fuzz the hell out of it to make the end point fall over or 2) hexdump the protocol and write pieces of it in ruby or python to get messages through so that you can fuzz the hell out of it in a structured way. And if there was some need to write a parser, you can bet it ain't gonna be LALR, it will be hand-crafted, likely recursive descent. To reply to each of your points: 1) If you are lucky, this XML. I don't need to know how to write a parser if the data is XML. If it is some sort of Java serialization, dejad is your friend--no parser required. If it is binary, you are going to use the protocol reversing route mentioned above. 2) See #1 3) Maybe just insert parentheses around the whole bit of data, and insert more strategically, and you are all but done. 4) See #3 or #1. 5) See #4. If I was working on a team, and I saw someone writing a parser for a data-related problem, I would seriously question what they are doing.

Locke1689 14y ago

The pedagogical value of writing a parser for your compiler for any language more complex than, say, Scheme, is basically zero. Skip the parser, learn the useful stuff.

eru 14y ago
Oh, writing parsers is useful outside of writing compilers. But yes, you shouldn't be writing parsers in low level languages like C++. Write them in OCaml or Haskell. It's a joy there.
- helmut_hed 14y ago
  This is my cue to mention Spirit http://boost-spirit.com/home/ http://boost-spirit.com/home/
bane 14y ago
unless you ever need to process data in a format for which a decent library doesn't already exist
- wglb 14y ago
  Do you have an example in mind of such data?
  - helmut_hed 14y ago
    New file formats of all kinds are invented every day, often with some proprietary tool attached. Writing your own parser allows you to add value and/or interoperate with the proprietary system. Even in the cases where an open source parser already exists it may have performance issues, or not support the latest version of the format. Being able to roll your own in those cases is empowering. Of course you asked for examples... let me give that a try: 1) data from your favorite application that's been end-of-lifed and you're thinking of replacing with a competitor's tool 2) data from a later version of your favorite application that you want to use with an earlier version, because you don't want to upgrade 3) configuration information from some part of your IT infrastructure that you need to refer to as you restructure and upgrade 4) a big config file for some software, that contains an error somewhere and "grep" won't find it. Maybe it's a semantic error, for example. 5) a config file for some ancient crufty software you're replacing, but the config file is huge and contains a lot of institutional knowledge, so you want to automatically translate it to the new system's setup. Being able to generate even simple parsers gives you a lot of power. It's not as uncommon as you might imagine.
    - wglb 14y ago
      Having been in the business of reversing data formats in two different real-world contexts, I feel comfortable in saying that just about the last thing I would do is write a parser. One context was building a system to pull live financial data feeds. The other is in the software security business. In the former, often CSVs were what you would get, or fielded data. We built an engine that could easily inhale these. Including the bloomberg feed which was unusually complex. In the security business, one is often asked to assess some not-very-well specified protocol, or some protocol for which there is no documentation. So to deal with it you 1) fuzz the hell out of it to make the end point fall over or 2) hexdump the protocol and write pieces of it in ruby or python to get messages through so that you can fuzz the hell out of it in a structured way. And if there was some need to write a parser, you can bet it ain't gonna be LALR, it will be hand-crafted, likely recursive descent. To reply to each of your points: 1) If you are lucky, this XML. I don't need to know how to write a parser if the data is XML. If it is some sort of Java serialization, dejad is your friend--no parser required. If it is binary, you are going to use the protocol reversing route mentioned above. 2) See #1 3) Maybe just insert parentheses around the whole bit of data, and insert more strategically, and you are all but done. 4) See #3 or #1. 5) See #4. If I was working on a team, and I saw someone writing a parser for a data-related problem, I would seriously question what they are doing.