I'm not sure if you meant this to be snarky but that's how it comes across to me! If your questions were genuine, then there are indeed good answers. > Why i

I'm not sure if you meant this to be snarky but that's how it comes across to me! If your questions were genuine, then there are indeed good answers. > Why is this a good design? It's simple, so it's a good design for expository purposes. > If I were writing a serious parser intended for human use with nice error messages, I would want to know the position and length of the parsed output That's roughly how the fastest Haskell parser, flatparse, works https://hackage.haskell.org/package/flatparse-0.5.0.1/docs/FlatParse-Basic.html#t:ParserT https://hackage.haskell.org/package/flatparse-0.5.0.1/docs/F... You could write a very similar article to this one about how flatparse's Parser type is a functor, and then someone could snarkily respond > So, on a successful parse, it returns the result and the index into the string that it has parsed so far. That’s seems error prone and rather weak. What ensures that the “index into the string that it has parsed so far” is, in fact, the true amount parsed? > If I were writing a parser for expository purposes, I would just return the unconsumed input. > So I’m confused. Why is this a good design?