Skip to content

New regex parser #170

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

Merged
merged 2 commits into from
Apr 5, 2022
Merged

New regex parser #170

merged 2 commits into from
Apr 5, 2022

Conversation

jamesdbrock
Copy link
Member

@jamesdbrock jamesdbrock commented Apr 1, 2022

Replace regex with different function.

Resolves #156 #157


Checklist:

  • Added the change to the changelog's "Unreleased" section with a link to this PR and your username
  • Linked any existing issues or proposals that this pull request should close
  • Updated or added relevant documentation in the README and/or documentation directory
  • Added a test for the contribution (if applicable)

@jamesdbrock jamesdbrock marked this pull request as draft April 1, 2022 09:35
@jamesdbrock jamesdbrock linked an issue Apr 1, 2022 that may be closed by this pull request
@jamesdbrock jamesdbrock marked this pull request as ready for review April 1, 2022 09:57
-- |
-- | [*MDN Advanced searching with flags*](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions#advanced_searching_with_flags)
mkRegex :: forall m. String -> RegexFlags -> Either String (ParserT String m String)
Copy link
Contributor

@natefaubion natefaubion Apr 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for choosing mkRegex? I don't think we use mk as a parser prefix anywhere else. I personally suggest just sticking to regex, as it also mirrors Data.String.Regex.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth exposing an unsafeRegex as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I renamed it to regex.

It's pretty easy to write unsafeRegex. I think I'd rather leave that to the users for now.

Just n' -> pure n'
Nothing -> fail "Expected number"
jsonNumber = case mkRegex """(\+|-)?(\d+(\.\d*)?|\d*\.\d+)([eE](\+|-)?\d+)?""" noFlags of
Left err -> unsafePerformEffect $ throw err
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can just be unsafeCrashWith.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok done.

test/Main.purs Outdated
Comment on lines 825 to 838
( let
prependContext m' (ParseError m pos) = ParseError (m' <> m) pos
p = region (prependContext "context1 ") $ do
_ <- string "a"
region (prependContext "context2 ") $ do
string "b"
in
case runParser "aa" p of
Right _ -> assert' "error: ParseError expected!" false
Left (ParseError message _) -> do
let messageExpected = "context1 context2 Expected \"b\""
assert' ("expected message: " <> messageExpected <> ", message: " <> message) (message == messageExpected)
logShow messageExpected
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that you can remove the parens and in.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The p was shadowing something else, so now those bindings are locally scoped.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I'm saying that, because you are in a do block, ending with a let/in like this is exactly the same as just using a let in the do block, with the last statement being the runParser. The parens don't do anything semantically. If inserting the parens, vs using a do/let results in different warnings, it's a bug in the compiler.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless more tests are added after this block. Anyway I deleted the parens.

@jamesdbrock jamesdbrock force-pushed the mkregex branch 3 times, most recently from 5f15a68 to e2e2acd Compare April 3, 2022 05:39
@jamesdbrock jamesdbrock changed the title Delete regex, replace it with mkRegex New regex parser Apr 5, 2022
@jamesdbrock jamesdbrock merged commit 43463e3 into main Apr 5, 2022
@jamesdbrock jamesdbrock deleted the mkregex branch April 5, 2022 01:36
@jamesdbrock
Copy link
Member Author

Thanks for the review @natefaubion !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants