Skip to content
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

Add support for dotAll flag? #150

Open
chtenb opened this issue Jun 4, 2021 · 5 comments
Open

Add support for dotAll flag? #150

chtenb opened this issue Jun 4, 2021 · 5 comments
Labels
status: needs more info This issue needs more info before any action can be done.

Comments

@chtenb
Copy link

chtenb commented Jun 4, 2021

The dotAll flag doesn't seem to be exposed in the Regex module. Could we add it?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp/dotAll

@JordanMartinez JordanMartinez added the status: needs more info This issue needs more info before any action can be done. label Dec 1, 2021
@JordanMartinez
Copy link
Contributor

Just a question. Is the dotall flag a JS-specific feature? If so, I'm guessing it can't be supported in other backends.

@chtenb
Copy link
Author

chtenb commented Dec 1, 2021

I'm only familiar with the JS backend. Which other backends do I need to check?

@JordanMartinez
Copy link
Contributor

See Actively Maintained

@garyb
Copy link
Member

garyb commented Dec 1, 2021

I'd never given much thought to regex compat across backends before, it's a pretty tricky issue! Even without considering options the meaning of a regex could differ between backends.

I was almost going to suggest regex should be split into its own js-regex library or something, but then this whole String library is generally very JS centric, given ucs-2, codepoint vs char, etc. 🤔

@chtenb
Copy link
Author

chtenb commented Dec 1, 2021

I wasn't aware those packages were also used when targetting other languages. TIL :)
If we want to transparently expose the native regex implementation of each language there's bound to be differences indeed.
Making a separate string library for each backend makes sense, but that also makes purescript generally less portable.
If we want to abstract over string implementations and string manipulation libraries to create an opaque PureScript string library, then that may be harder to implement for each backend. I'm also not sure if that would have too much impact on string performance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs more info This issue needs more info before any action can be done.
Projects
None yet
Development

No branches or pull requests

3 participants