Original text:
The behaviour of operators is consistent with the 'C'-family of programming languages.  3.5.9.2. The "filter-selector" works with arrays and objects exclusively.  Its

Reviewer comments:
Generalise comparisons Make regex operator conform to Perl etc. Add operator precedence table Fixes URL Fixes URL Fixes URL
I think having the precedence table now, above remark is obsolete.
Thanks NAME I raised URL to remove that remark.
Perl introduced as (where regexp actually could be a substitute operator etc.). Ruby generalized this to and . (Java, JavaScript, Python, PowerShell don't have an operator at all; this is all handled using method calls.) So if we want to have syntax for regexp matching, we probably want to go with Perl's. Originally posted by NAME in URL
Introducing an operator precedence table will help us comunicate what we are trying to achieve precedence-wise in the ABNF syntax. Originally posted by NAME in URL
Here is a first version ... taken from
Thanks for that NAME I suggest we combine the third and fourth rows and give and the same precedence as the other comparison operators as I don't think there is a situation where their relative precedence is necessary. Also, having a separate row for and gives the impression we want to entertain expressions such as: and which I'd prefer to avoid
Yes ... so ...
Currently, filter comparison require a path on the left hand side and a constant expression on the right hand side. This seems overly restrictive. We should generalise it to allow the opposite order as well as path to path comparisons and, for completeness, constant expression to constant expression comparisons. For example, the following comparisons should be valid:
Should be symmetric, too?
Did you mean (which is what we use in the current draft)? I think not because its operands have distinct types and it's probably easier to police restrictions and give good diagnostics if we keep asymmetric. For instance, with the current syntax: can fail with an error such as "NAME needs to be a regular expression literal", which is a bit easier to understand than something like "one side of ~= needs to be a regular expression literal". Having said that, other generalisations of may be worth it, such as allowing a string literal (rather than only a path) on the left hand side, for consistency with the above syntax for the other comparison operators, but even that could be give rise to confusion, e.g.:
Oops. It really should be . Perl introduced as (where regexp actually could be a substitute operator etc.). Ruby generalized this to and (actually, even more general...). Java, JavaScript, Python, PowerShell don't have an operator at all; this is all handled using method calls. So if we want to have syntax for regexp matching, we probably want to go with Perl's. We also need to discuss whether we need syntax for regexp literals. But this is maybe leading beyond this github issue.
When witing the current node represented by will be selected. So resulting in the same as . Is this really, what we want?
Anything else we might want? (I'm not sure we can write a syntax that only lets "meaningful" expressions through.)
Convinced ... you made the point.
This looks good. Just some curiosity questions from me.

Revised text:
The behaviour of operators is consistent with the 'C'-family of programming languages. <ins> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly). </ins> 3.5.9.2. The "filter-selector" works with arrays and objects exclusively.  Its