search

opencypher / openCypher

Specification of the Cypher property graph query language
http://www.opencypher.org
Apache License 2.0
856 stars 150 forks source link

Checking grammar definition with the BNF Converter #240

Closed walter-weinmann closed 7 years ago

walter-weinmann commented 7 years ago

I have checked the current status of the grammar definition (EBNF version as of June 21, 2017) with the BNF Converter. The following issues were discovered:

Unused rules:

  1. one of (hence also reduce / reduce conflict): 
    
PatternElement = (NodePattern, { [SP], PatternElementChain })
           | ...

RelationshipsPattern = NodePattern, { [SP], PatternElementChain }- ;

2. one of (hence also reduce / reduce conflict):

ReservedWord = (A,L,L) | ...

SymbolicName = ... | (A,L,L) | ...

Reduce / reduce conflicts:
---
1. MapLiteral :

Properties = MapLiteral | ...

Literal = ... | MapLiteral | ...

2. Parameter :

Properties = ... | Parameter ;

Atom = .. | Parameter | ...



Is there any chance of solving these issues in the grammar definition ?
Mats-SX commented 7 years ago

@walter-weinmann Thanks for reporting this. So the problem is that these rules occur with the same definitions in multiple places? Do you think that simply refactoring them to their own rules and referencing that rule in the current places would be enough?

EDIT: On second thought, that doesn't seem like a solution at all to your second headline. I don't think I quite understand what the problem is. Is it because (to take one example) Properties and Literal are both valid in some position, and they both expand to a matching rule (MapLiteral) which causes an ambiguity?

walter-weinmann commented 7 years ago

@Mats-SX My problem is that I'm using a LALR parser, namely yecc, which is the Erlang foe to yacc. LALR parsers are however bottom up parsers with only limited lookahead.

Mats-SX commented 7 years ago

@walter-weinmann I don't think I understand exactly what the problem is, so I don't know how to solve it. Your first headline reads 'unused rules', but I don't understand in what sense they are unused? It's certainly possible to write a query which will use any or both of these rules.

Do you have a particular query that is impossible to parse?

For ALL, I think that's a bug and should be removed. ALL is reserved, and not allowed as a symbolic name (pushed a fix).