4 ms·

A parser is not a functor, you can represent a parser as a frankensteined combination of functors. What I'm saying is that you probably shouldn't.

itishappy 3y ago
Can you say why? I'm struggling to understand your point.
- alexvitkov 3y ago
  My point is that parsers structured as a combination of parser combinators are worse than hand-rolled parsers, because: 1. It's not hard to write a parser, and one you it's a problem you don't have to solve very often, so the ungodly amount of time people spend thinking about their formal properties and attempting to come up with new parsing methodologies is baffling. Just witnessing the literature leads people to believe writing a parser by hand is some Herculean task, they don't attempt it, they pick up a weird parser combinator library and have bad time. 2. You're limited by what can be expressed by your parsing methodology of choice, which usually means a context-free grammar. There's even fairly basic formats that can't be expressed as a CFG (https://en.wikipedia.org/wiki/Bencode https://en.wikipedia.org/wiki/Bencode). If you're sure your requirements won't change, this is not an issue, but if you're not, a custom parser can give you peace of mind, since it can be extended with literally anything thrown your way. 3. Performance
  - aidenn0 3y ago
    > ...pick up a weird parser combinator library and have bad time. > You're limited by what can be expressed by your parsing methodology of choice, which usually means a context-free grammar. I know those two quotes were from separate points, but parser combinators are not limited to CFGs; pretty much any recursive-descent parser (parser combinators included) will have zero issue with your Bencode example. I pretty much agree with the rest of your post, except for the fact that it's unusual for an entire year to go by in which I don't write a parser. Also, some parser libraries (though not parser combinators) can statically find ambiguities in grammar definitions, which can be helpful if you are designing the language.
  - hardware2win 3y ago
    I agree with this I struggled with this formal bullshit despite having exp. with handwritten parsers for PL.

itishappy 3y ago

Can you say why? I'm struggling to understand your point.

alexvitkov 3y ago
My point is that parsers structured as a combination of parser combinators are worse than hand-rolled parsers, because: 1. It's not hard to write a parser, and one you it's a problem you don't have to solve very often, so the ungodly amount of time people spend thinking about their formal properties and attempting to come up with new parsing methodologies is baffling. Just witnessing the literature leads people to believe writing a parser by hand is some Herculean task, they don't attempt it, they pick up a weird parser combinator library and have bad time. 2. You're limited by what can be expressed by your parsing methodology of choice, which usually means a context-free grammar. There's even fairly basic formats that can't be expressed as a CFG (https://en.wikipedia.org/wiki/Bencode https://en.wikipedia.org/wiki/Bencode). If you're sure your requirements won't change, this is not an issue, but if you're not, a custom parser can give you peace of mind, since it can be extended with literally anything thrown your way. 3. Performance
- aidenn0 3y ago
  > ...pick up a weird parser combinator library and have bad time. > You're limited by what can be expressed by your parsing methodology of choice, which usually means a context-free grammar. I know those two quotes were from separate points, but parser combinators are not limited to CFGs; pretty much any recursive-descent parser (parser combinators included) will have zero issue with your Bencode example. I pretty much agree with the rest of your post, except for the fact that it's unusual for an entire year to go by in which I don't write a parser. Also, some parser libraries (though not parser combinators) can statically find ambiguities in grammar definitions, which can be helpful if you are designing the language.
- hardware2win 3y ago
  I agree with this I struggled with this formal bullshit despite having exp. with handwritten parsers for PL.