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

Idea: Adding a Numeric Quanitfier Feature for Grammars #215

Open
im-deepfriedwater opened this issue Mar 26, 2018 · 1 comment
Open

Idea: Adding a Numeric Quanitfier Feature for Grammars #215

im-deepfriedwater opened this issue Mar 26, 2018 · 1 comment

Comments

@im-deepfriedwater
Copy link

im-deepfriedwater commented Mar 26, 2018

It would be useful in certain situations to specify a numeric amount of repetitions. For example, in JavaScript regexes I could do:

/[0-9A-F]{4}/i

Ohm could have similar convenience benefits, especially if a user might want a rule to require a specified amount of "things" without having to copy and paste said "thing" for however many repetitions they want.

@MuhammedZakir
Copy link

From #310 :

@MuhammedZakir Can you add some more details about your use case to #215?

Before going further, I would like to mention that I didn't "need" numeric quanitifer as much as I thought I would.

I was trying to write a grammar for Markdown parser according to CommonMark spec [1]. As you know, in Markdown, indenteding a line by 4+ spaces [2] will make it a code block. For this use case, I use lookahead for a string of 4 spaces. This works for me and I personally didn't need this feature (at least for now).

However, I can see this will be slightly ugly if, for example, trying to match a rule or a bigger string x number of times. This will also be problematic if there are a bunch of rules where we need an exact number of matches. Dong the way I am doing right now will make the grammar too verbose (which make it harder to read) and error-prone (when modifying).

Re: about using semantic action: I gave it some thought, but didn't like it (for my case). Because if I do it like that, I will have to parse each block again if the indentation is less than 4 spaces. This is probably not a problem per se, but I find this unsatifactory.

[1] https://spec.commonmark.org/0.30/
[2] 4 spaces or 1 tab or a mixture of them

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

No branches or pull requests

3 participants