> No, a parser is not an functor, an applicative or god forbid a monad.
What? The post gives a proof of how they are, and you just assert the result is wrong with no evidence whatsoever.
What? The post gives a proof of how they are, and you just assert the result is wrong with no evidence whatsoever.
However, I might argue that calling the function a "parser" is a bit of a stretch. In a toy, abstract sense, sure, and maybe there's a formal definition of "parser" that it conforms to, but just because it's named a "parser" doesn't really mean that's all a "parser" is when we talk about it in other contexts.
Parsers, to me, in a professional software engineering sense, need to have error handling, performance and memory guarantees, the ability to do "best case" parsing and return a number of errors all at once, and so on.
So one interpretation of "No, a parser is not a functor", despite the proof here, is "I reject that the toy example here being called a parser is sufficiently close to what I would call a 'parser', and what a 'parser' is to me is not a functor [because of these other things not captured by the example]".
I tend to agree with that. Haskellers don't have an exclusive claim to terminology, and I don't think "parser" is defined formally enough that we all must agree on it.
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). 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
> 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.
I struggled with this formal bullshit despite having exp. with handwritten parsers for PL.