-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lookAhead consumes input on failure #73
Comments
I would like to provide a pull request to fix this. Should I adapt the documentation or adapt the code? |
The semantics of
There's probably a reason why Megaparsec does it this way. https://hackage.haskell.org/package/megaparsec-9.2.0/docs/Text-Megaparsec.html#v:lookAhead Parsec does the same thing. https://hackage.haskell.org/package/parsec-3.1.15.0/docs/Text-Parsec.html#v:lookAhead I would like to understand the reason why Parsec and Megaparsec |
purescript-parsing |
My suspicion is that they defined it this way for reasons of orthogonality. As they mention, one can combine it with However, while this is valid, I would argue that this is not what users would expect under the name "lookAhead". |
To elaborate a bit more on the name "lookAhead", I think users would intuitively expect that Is what comes next of the form Failing to execute The way that mega parsec has defined it is more about really running the parser but keeping the previous positional context in case of success. Maybe a name like |
Everything you say sounds convincing, but the current situation is that all the major Haskell libraries which are similar to purescript-string-parsers think that
In fact I'm starting to think that purescript-parsing is the one package that's doing this wrong.
|
I agree that compatibility with existing parsec-like libraries is something that improves user experience.
I'm not a 100% sure as to what to call this function though. Do you have any suggestions?
|
Why not update |
Yes that I what I proposed in my last post. But not clear enough apparently :) Also, note that currently lookAhead already matches what others do (except purescript-parsing), and this issue was about changing that. So it wouldn't be breaking for purescript-string-parsers. |
( I actually had the yeses and noes incorrectly reversed on the table above so I edited the table and now it's correct. ) |
I personally think the best solution here is lots of good documentation. All of the Haskell libraries explain very directly that the |
Yes that too. The documentation is incorrect at the moment. Still I would also have the composition as a separate function. Do you have objections to that? |
I got tripped up by this. I'm still not sure how to get the behavior I'm looking for. What's the recommended way to not consume input when using |
I think the answer is |
Yes, tryAhead is the way. If you find the documentation not clear enough in this regard, feel free to improve it and provide a PR. |
Describe the bug
As you can see from the definition the suffix is "reset" to
s
in case of success, but in case of error the error is passed on as is, meaning thePosString
at the failure is propagated.Expected behavior
I would expect the function to do what its documentation suggests: to not consume any input. Or if this is really not intended I would expect the documentation to be correct and not misleading.
Additional context
This cost me quite some debugging time :) I'm currently working around it by using
try $ lookAhead
everywhere.The text was updated successfully, but these errors were encountered: