-
Notifications
You must be signed in to change notification settings - Fork 11
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
Start working on a RegEx dialect as a normalization showcase. #210
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fodinabor
force-pushed
the
feature/regex-dialect
branch
from
May 5, 2023 11:57
bb305ea
to
4508968
Compare
Merged
This phase replaces the regex axioms with calls to annexes that implement the regex matching. Thus far the `cls`s and `conj` are implemented. Note, `conj` only works with uniform `cls`s as paramters so far..
This allows PE of the impl without needing copy prop through branches.
Also make `disj` normalization fold `lit`s into already present `cls`s
Enjoy with caution. :)
Fix normalizers with ranges.
Probably not exhaustive..
fodinabor
changed the title
WIP: Start working on a RegEx dialect as a normalization showcase.
Start working on a RegEx dialect as a normalization showcase.
Jun 9, 2023
leissa
reviewed
Jun 20, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fantastic work :)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A simple use case that showcases the power of the normalization framework present in Thorin is regular expressions.
Defines a set of axioms that represent ranges, any character, alternatives, sequences and quantifiers.
These should be sufficient to define (most) compile-time regular expressions (missing
{n,m}
quantifiers, lookaheads, .. atm)Accompanying the axioms are normalizers that simplify the RegEx.
An example of normalization is quantifier merging:
(\d*)?
,(\d?)*
,(\d+)?
,(\d?)+
,(\d*)+
,(\d+)*
all normalize to\d*
.For disjunctions: duplicates are removed, opposite classes (e.g.
[\s\S]
) are reduced to match any character ".
".All classes and literals are translated to disjunctions of ranges and the ranges are merged.
Disjunctions and conjunctions are always normalized to only have two arguments to make the matcher impl simpler.
There is also a phase that recursively replaces the applied regex with rather primitive matcher functions.
Therefore we can actually match the regex. Note, currently only deterministic regex can be matched ->
\w\w+
works, but\w+\w
doesn't.https://github.com/fodinabor/thorin_regex_benchmark contains a benchmark comparing Thorin's against CTRE, PCRE2 and
std::regex
:Which looks pretty favorable for thorin on this regex benchmark.
Similarly, the compilation time of the thorin matcher is looking good (note, pcre2 performs runtime compilation, not measured by either of the metrics):