Support for chaining multiple 'or' / 'and' operators

[Hughp135]

I was surprised to find out that you cannot chain multiple and / or conditions after each other?

For example, this results in a syntax error:

// Input:
[
  {"name": "Chris", "age": 23, "city": "New York"},
  {"name": "Emily", "age": 19, "city": "Atlanta"},
  {"name": "Joe", "age": 32, "city": "New York"},
  {"name": "Kevin", "age": 19, "city": "Atlanta"},
  {"name": "Michelle", "age": 27, "city": "Los Angeles"},
  {"name": "Robert", "age": 45, "city": "Manhattan"},
  {"name": "Sarah", "age": 31, "city": "New York"}
]

// Failing queries:
filter((.city == "New York") and (.age > 30) and (.name == "Sarah"))
filter((.city == "New York") or (.age > 30) or (.name == "Sarah"))


// Result:
SyntaxError: Character ',' expected (pos: 45)

The only way I found around this was to nest the conditions resulting in ugly queries:

filter(
  or (
    (.city == "New York") or (.age > 30),
    (.name == "Sarah")
  )
)

Or for a more verbose example:

filter(
  or (
    (.city == "New York"),
    or (
      (.name == "Sarah"),
     or (
        (.name == "Emily"),
        or (
          (.name == "Kevin"),
          or (
            (.name == "Michelle")
          )
        )
      )
    )
  )
)

Surely this isn't how people are expected to use the library? So I think if the or and and functions could support multiple parameters, it would be a lot simpler.

Suggested Changes:

// Should be valid:
(.name == "Sarah") or (.name == "Emily") or (.name == "Kevin")

// Should also be valid:
or (
  (.name == "Sarah"),
  (.name == "Emily"),
  (.name == "Kevin")
)

[josdejong]

Thanks for your suggestion @Hughp135. Letting or and and support more than two conditions would be a great improvement, it has been on my wishlist for some time already. Similarly, it may be nice to support more than two arguments for add, subtract, multiply, and divide.

As for your workaround, this can be a bit simpler than your example: you have to wrap every (a or b) in parentheses:

// not working:
filter((.city == "New York") or (.age > 30) or (.name == "Sarah"))

// working:
filter(((.city == "New York") or (.age > 30)) or (.name == "Sarah"))

One interesting question is whether we would like to support a mix of or and and. That is relatively complex since then we have to introduce operator precedence. I'm not sure whether we need that: in general, it is a good idea to wrap your conditions in parentheses then anyway to prevent unexpected results.

[Hughp135]

@josdejong Thanks for the reply.

The operator precedence logic is a challenge I guess. Perhaps that could be implemented later, and first it could be recommended within the docs to not mix and with or expressions within the same parenthesis?

The simpler format you suggested would fail to work with more than 4 conditions, so it eventually has a similar issue:

// This is fine
((.a == 0) or (.b == 0)) or ((.c == 3) or (.a == 0)) 

// This fails with  SyntaxError: Unexpected part 'or ((.c == 3) or (.a == 0))' (pos: 53)
((.a == 0) or (.b == 0)) or ((.c == 3) or (.a == 0)) or ((.c == 3) or (.a == 0))

I tried a very simple code change to fix the and/or functions. But this only works with JSON input / function format, not operator chaining.

// functions.ts
  and: buildFunction((...args) => args.every(arg => !!arg)),
  or: buildFunction((...args) => args.some(arg => !!arg)),

// test cases in compile.test.json
    {
      "category": "and",
      "description": "should evaluate multiple and conditions",
      "input": { "a": 1, "b": 2, "c": 3 },
      "query":   [
        "and",
         ["eq", ["get", "a"], 1],
         ["eq", ["get", "b"], 2],
         ["eq", ["get", "c"], 3]
      ],
      "output": true
    },
    {
      "category": "or",
      "description": "should evaluate multiple conditions",
      "input": { "a": 1, "b": 2, "c": 3 },
      "query":   [
        "or",
         ["eq", ["get", "a"], 0],
         ["eq", ["get", "b"], 0],
         ["eq", ["get", "c"], 3]
      ],
      "output": true
    },

// parse.test.json
{
          "input": "(.a == \"0\") or (.b == \"0\") or (.c == \"3\")",
          "output": [
            "or",
             ["eq", ["get", "a"], 0],
             ["eq", ["get", "b"], 0],
             ["eq", ["get", "c"], 3]
          ]
}
// results in SyntaxError: Unexpected part 'or (.c == "3")' (pos: 27)

// This works though:
{
          "input": "or ((.a == 0), (.b == 0), (.c == 3))",
          "output": [
            "or",
             ["eq", ["get", "a"], 0],
             ["eq", ["get", "b"], 0],
             ["eq", ["get", "c"], 3]
          ]
}

[josdejong]

yes, let's focus on adding support for multiple arguments and leave operator precedence out of this for now. Support for multiple arguments will have to be implemented both in the functions as well as the parser and stringifier.

In your example with 4 conditions, you again have a case like a or b or c. When you wrap one of the two or operators in parenthesis, like (a or b) or c, it will work.

[josdejong]

Some thoughts:

1. If only some of the operators support more than two arguments, the parser needs to know which operators support it. Alternatively, the parser can parse these cases in multiple nested function calls like ["and", 1, ["and", 2, 3]], so there is no need to add support in the functions themselves. Only downside of that would be that support for multiple arguments is not available in the JSON format.
2. Maybe, implementing support for operator precedence isn't that complicated, we have to look into it. It would seriously improve the API compared to "just" partially supporting multiple arguments for operators, which may turn out to be confusing from a user perspective.
3. If we do implement operator precendence, I think we do not need the function implementations to support more than two arguments, then it's all handled by the parser, parsed into nested calls like explained in (1).

[josdejong]

I've started an experiment with operator precedence here: #17

[josdejong]

@Hughp135 can you have a look at the description of #17 and read about the breaking changes? Configuring custom operators and functions will become more complex, though also more flexible: you can now remove functions/operators that you don't want. What do you think?

[github-actions]

🎉 This issue has been resolved in version 5.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀