-
Notifications
You must be signed in to change notification settings - Fork 10
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
Check regexes at compile #8
Comments
It would. But do you have a way of doing that in mind? |
There's not much you can do with type-level strings even in GHC 8.2.
There's probably a type checker plug in somewhere, or a macro would work,
but those have the obvious drawbacks.
…On Feb 14, 2018 7:14 AM, "Denis Redozubov" ***@***.***> wrote:
It would. But do you have a way of doing that in mind?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACNoMUjD7LdVc2iTI5NEpPv3jwP33UtSks5tUvgsgaJpZM4SFdu4>
.
|
However, a type-level regex representation, well it's convenient, could
work.
Like a data kind for each case:
data REGEX = LITERAL Symbol | STAR REGEX | ...
…On Feb 14, 2018 2:11 PM, "Spiros Boosalis" ***@***.***> wrote:
There's not much you can do with type-level strings even in GHC 8.2.
There's probably a type checker plug in somewhere, or a macro would work,
but those have the obvious drawbacks.
On Feb 14, 2018 7:14 AM, "Denis Redozubov" ***@***.***>
wrote:
> It would. But do you have a way of doing that in mind?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#8 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ACNoMUjD7LdVc2iTI5NEpPv3jwP33UtSks5tUvgsgaJpZM4SFdu4>
> .
>
|
I've thought about the type level representation, but I would rather separate something like this to a different project before trying to incorporate it into schematic. Schematic already incurs heavy compilation burden on ghc and I think it can get worse with type level regexes. Do you think some helpers to test out the type level regexes would come in handy? It may be an alternative. |
Yeah, wrapping whatever regular expression parser is eventually invoked makes sense. |
Change Min, Max, Sort, Length benchmarks
Currently regular expressions (
TRegex
forSchemaText
) get compiled only when (and if) relevant data being validated at run-time. Thus even malformed regexes pass compilation and might sleep past testing. It would be nice if they get compiled or syntactically verified while compiling Haskell.The text was updated successfully, but these errors were encountered: