Let ReadP carry a failure message

[Carter Schonwald]

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 <david.feuer at gmail.com> 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 <ndospark320 at gmail.com> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20201119/ca824568/attachment.html>