Parse error due to select option order about bnf-parser HOT 8 CLOSED

"bnf-parser": "^3.1.1",

I will try to make a better report. (already deleted everything after it failed xD)

from bnf-parser.

What version of the package are you using?
Because both of those parse for me

from bnf-parser.

I'm adding this as a automated test case just in case for future builds, however NPM is down for me and I want to make sure the two syntaxes from the different BNFs should make identical output syntax trees

from bnf-parser.

I managed to replicate your error - I have no idea how I didn't run into this when I have an actual programming language running off this as the syntax parser 😅

from bnf-parser.

All good. I needed a bnf parser yesterday and started to built one. Then I realized that, what I reported above, won't be handled by my parser and so I started to look out for existing solutions. (yours is the first I checked)

from bnf-parser.

I thought it was a bug just like you, but I realized it's actually expected behavior - the library assumes not parsing the whole string is a failure. So in your second case it would match the "a", then the program ends, but there is still a remaining character so it fails.

For both cases to be valid you would need to write it like this:

case1 ::= ( "a" | "aa" )+
case2 ::= ( "aa" | "a" )+

Ideally you should order your selects so options are ordered with the most unique and complex elements first.
I have literally thought my parser was broken before, then realizing actually I was just telling it to do the wrong thing.

from bnf-parser.

All good. I needed a bnf parser yesterday and started to built one. Then I realized that, what I reported above, won't be handled by my parser and so I started to look out for existing solutions. (yours is the first I checked)

• @tippfelher

Yeh, that's basically why I started mine as well, plus why I adapted BNF syntax to have the ommit character for easy clean up and stuff - the only thing I'm really unhappy with atm is the fact that sometimes it gives the wrong reference range for a syntax error.

i.e. if you have a syntax error in a function, it complains it can't parse at the start of the function body, instead of at the statement in the function

from bnf-parser.

@tippfelher, this might be a bit late, but I was thinking there are probably other people like you who expect a more non-deterministic select statement.
I was wondering do you think it would be worth adding a variant of || form |, where if you use || it will match all cases then return the best (consumes the most tokens) result, and | always just returns the first match. Thoughts?

It wouldn't be that hard to implement, since I am already comparing 'best result' of errors on a switch, so it returns the error from the option that got the furthest in consuming

from bnf-parser.