Re: Let ReadP carry a failure message

Excellently said! Good parser abstractions include a lot of extra info like source span, context. And or even what the actual expected vs seen token are. And the proposed extension doesn’t seem to provide for those. On Thu, Nov 19, 2020 at 10:27 PM David Feuer wrote:

My main concern is that while you'll get error messages from parse failures, they may not actually do a good job of pointing to the cause of the failure. I don't know much about parsing, but I gather that a lot of people have put a lot of work into designing parsing frameworks with decent error reporting, and you're not likely to get anything near that by grafting errors onto a more primitive system.

On Thu, Nov 19, 2020, 10:25 PM Dannyu NDos wrote:

...

Well, I once tried implementing a parser that evaluates integer addition, multiplication, exponential, tetration, pentation, and so on infinitely. The operators were + with precedence 6, * with precedence 7, ^ with precedence 8, ^^ with precedence 9 (for tetration), ^^^ with precedence 10 (for pentation), ^^^^ with precedence 11 (for hexation), and so on infinitely. I've not succeeded implementing it using ordinary ReadP.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries