-
Notifications
You must be signed in to change notification settings - Fork 132
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
RegexParsers: skipWhitespaces when using implicit conversion from a character #320
Comments
Imported From: https://issues.scala-lang.org/browse/SI-6491?orig=1 |
I just tried making a scanner and discovered this issue. I tried to work around it by creating a separate scanner object with different whitespace behavior but haven't been able to get this to work. Is there an intended way to handle whitespace in string/char literals? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(I wanted to lower the priority of this issue, but somehow wasn't allowed to do so in the bug filing form)
A RegexParsers parser should skip whitespaces. It does so by omitting them in advance of each parsing step (so for example the literal("bla") parser at first skips all the whitespaces and then parses the literal "bla").
A string s is implicitly converted to a literal(s) parser. So writing
class MyParser extends RegexParsers {
def text = "first"|"second"
}
will parse "first" or "second" with arbitrary whitespaces in front of them.
A character c is implicitly converted to accept(c). accept() is defined in Parsers and not in RegexParsers, so the whitespaced aren't skipped here.
class MyParser extends RegexParsers {
def text = 'f'|'s'
}
will parse "f" or "s" but only if there aren't whitespaces in front of it.
This is somehow inconsistent and it took me a long time to realize it when I tried to write a string parser like
I think RegexParsers should override the parsers from its parent class and also skip whitespaces in front of them.
The text was updated successfully, but these errors were encountered: