-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
re/nre: mention nim-regex as the alternative #17926
Conversation
I agree; But this kinda leaves stdlib without Regex, thats a big missing feature compared to other programming languages... Work to integrate |
Agreed that we should incorporate this awesome library into stdlib. There are multiple ways we can achieve this, depends on how the library's author wants the library to evolve (outside stdlib in its own repo or not). If in its own repo then the only way I can see this working is if we implement a feature in Nimble that allows packages to be included as part of Nim, and that then Nimble is aware that these packages are "installed". |
The "nim distro" idea. It's time to do it. |
Why not use one of the adminitions (like |
pros of pkg/regex: better API, pure nim performance wise, see this thread: nitely/nim-regex#57 tracking performance which was initially showing regex being 40x slower but @nitely has improved performance a lot since then, eg see nitely/nim-regex#58 (comment). IMO we should still provide a comprehensive (and easy to re-run / update) benchmark on a variety of tasks before declaring pkg/regex as "the one true choice" |
All I can say is nim-regex depends on @timotheecour performance concerns are valid, we need more benchmarks. Why is re/nre outdated anyway? is this about the APIs, requiring pcre VS no dependencies, or what exactly? |
For me it's about "requiring pcre VS no dependencies" plus the fact that both re/nre are hardly maintained. |
Or, we can just recommend people download the package, while carefully considering whether that implementation is suitable for inclusion into the standard library in the first place. Nim has already gone through 2 regex modules, let's try to avoid continuing the trend. |
@@ -10,6 +10,9 @@ | |||
when defined(js): | |||
{.error: "This library needs to be compiled with a c-like backend, and depends on PCRE; See jsre for JS backend.".} | |||
|
|||
## NOTE: The `re` module is outdated, but going to be kept for backward |
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.
## NOTE: The `re` module is outdated, but going to be kept for backward | |
## .. note:: The `re` module is outdated, but going to be kept for backward |
ditto
@@ -9,6 +9,9 @@ | |||
when defined(js): | |||
{.error: "This library needs to be compiled with a c-like backend, and depends on PCRE; See jsre for JS backend.".} | |||
|
|||
## NOTE: The `nre` module is outdated, but going to be kept for backward |
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.
## NOTE: The `nre` module is outdated, but going to be kept for backward | |
## .. note:: The `nre` module is outdated, but going to be kept for backward |
note or warning
Maybe a tiny new module on top of existing Regexes, multi-backend regex, kinda like: initRe(backend = JsRe) # backend = Nre , backend = X
let r: Regex = /[0-9]/i # Generates newRegex("[0-9]", "i") Then maybe users can "hook up" their own: initRe(backend = CustomTypeOrConcept) # Backend delegated to user.
let r: Regex = /[0-9]/i # Features and Bugs here delegated to user. |
No description provided.