opencypher / openCypher

Line 208 in b60f0f8

Here NOT is repetitive. Allowing expressions like NOT NOT NOT exp.

First thing is that the name of the grammar rule NotExpression i expect there to be a NOT but the NOT is now optional. So for semantics this seems more wieldy but better:

Instead of

  <production name="AndExpression" rr:inline="true">
    <non-terminal ref="NotExpression"/>
    <repeat>&SP; AND &SP;<non-terminal ref="NotExpression"/></repeat>
  </production>

  <production name="AndExpression" rr:inline="true">
    <alt>
      <non-terminal ref="NotExpression"/>
      <non-terminal ref="ComparisonExpression"/>
    </alt>
    <repeat>
      &SP; AND &SP;
      <alt>
        <non-terminal ref="NotExpression"/>
        <non-terminal ref="ComparisonExpression"/>
      </alt>
    </repeat>
  </production>

Secondly is that i think when the user writes nested NOT's it's going to include parenthesis, like: NOT (NOT (A OR B) AND (C XOR D)), this case is already covered by the fall through of the chain:

OrExpression
XorExpression
AndExpression
NotExpression
ComparisonExpression
AddOrSubtractExpression
MultiplyDivideModuloExpression
PowerOfExpression
UnaryAddOrSubtractExpression
StringListNullOperatorExpression
PropertyOrLabelsExpression
Atom
ParenthesizedExpression

So my main point is that i think it would be more likely that the user writes NOT NOT by accident (and thus introducing bugs) then having the "convenience" of not being required to place parenthesis.

If I understand you correctly, you are suggesting two changes:

Change definition of AndExpression in order for ComparisonExpressions to not be considered NotExpressions (remove the hierarchy). Your code proposal makes sense, but I wonder how you imagine redefining NotExpression consistently?

It currently looks like this:

  <production name="NotExpression" rr:inline="true">
    <repeat>NOT &WS;</repeat>
    <non-terminal ref="ComparisonExpression"/>
  </production>

Enforce parentheses for all NotExpressions. Although I agree that in many cases including the parentheses would improve the readability of the query, it would at the same time make some predicates somewhat tedious to write:

MATCH (a:Node)
WHERE NOT (a.booleanProperty)
...

Interesting idea!

Redefining the NotExpression

  <production name="NotExpression" rr:inline="true">
    NOT &WS
    <non-terminal ref="ComparisonExpression"/>
  </production>

MATCH (a:Node)
WHERE NOT (a.booleanProperty)

I believe this is not needed to write it this way, i could be written as

MATCH (a:Node)
WHERE NOT a.booleanProperty

Only in the case where you want to put a double NOT you would need parenthesis

MATCH (a:Node)
WHERE NOT (NOT a.booleanProperty)

This behaviour is the same in the current way NotExpression works and also in the way i propose to change NotExpression.

After NOT optional (current situation) or mandatory (proposal) follows ComparisonExpression, this falls through to PropertyOrLabelsExpression which i believe can represent the part a.booleanProperty it's therefor not needed to fall through more first onto ParenthesizedExpression which contains ( Expression ) in which case Expression would fall through ComparisonExpression (in my proposal) or NotExpression (with NOT part not being used) .. all the way to PropertyOrLabelsExpression again.

If this is hard to follow, it's because the fall through with the grammar is not so easy to understand. I understand this chain is needed in order to capture precendence. Perhaps there is an opportunity to lift some things to higher levels which are not precendence - sensitive ... but i won't go into that in this ticket.

By the way you can highlight your snippets of xml when you put three backticks immediately followed by the word xml

Aha, I get it. Then your idea makes even more sense. I agree that supporting NOT NOT NOT foo over NOT (NOT (NOT foo))) seems unnecessary.

Thanks for the hint on highlighting!

Hello, we had a conversation about this and came to the conclusion that the suggestion makes sense. However, we don't see enough value in practice to making this change right now. After all, no one is forced to write NOT multiple times and the damage is minimal if they do. Introducing this change in the grammar would likely lead to small but relevant changes to the AST produced by the openCypher parser. We currently don't think that the adjustments this would force on implementers and users are justified by the benefit. Also, an implementation of course could generate a warning when it detects a chain of NOTs. In any event, we will pick this up for GQL and aim to not not not ;) allow it there.

Closing for now; please re-open if you feel strong about this.

unlimited amount of NOT