Predicate is_infix_op_call returns false for many infix operators

[bellon-tiobe]

The fact is as the title says: that predicate returns false for the node representing all the following operators (and surely more): =, ==, ===, !=, !==, &&, ||, +=, -=, *=, /=, \=, &=, |=, ->.

Is this a bug? Or am I missing something?

[pfitzseb]

That's intended behaviour. Some infix operators are parsed as calls, others not:

julia> Meta.show_sexpr(Meta.parse("1 + 2"))
(:call, :+, 1, 2)
julia> Meta.show_sexpr(Meta.parse("1 && 2"))
(:&&, 1, 2)

You might be looking for is_operator instead?

[bellon-tiobe]

Thank you, Sebastian.

I want to know whether an operator is infix, prefix or postfix (I can't think of a postfix one right now, though). There are operators which can be unary or binary, like -, and telling the difference between those is a major reason for using a parsing framework instead of just regular expressions.

I already use is_operator, but I wrote this code to add the "missing" operators:

function is_op_call(node::TreeType)
    return  is_prefix_op_call(node) ||
            is_infix_op_call(node)  ||
            is_postfix_op_call(node)
end
function is_infix_op_call(node::TreeType)
    return JSx.is_infix_op_call(node) ||
           kind(node) in KSet"== === = != !== && || += -= *= /= \= &= |= ->"
end

I know that + and * are multi-operand operations, like in Lisp: (+ 1 2 3) => 6.

julia> JS.parsestmt(JS.SyntaxNode, "x + y + 2 + z")
line:col│ tree                                   │ file_name
   1:1  │[call-i]
   1:1  │  x
   1:3  │  +
   1:5  │  y
   1:9  │  2
   1:13 │  z

(I find it confusing that the single operator in the tree is in second position, not first).

But those 2 are not the only ones which are considered infix operators by the predicate in question, so, why are some operators parsed as calls? And what is the rule to know which is which?

[pfitzseb]

As you observed, there are two types of infix operators -- those that you can use in "call position":

julia> (!=)(a,2)
true

julia> JS.parse(JS.SyntaxNode, "a!=2")
line:col│ tree                                   │ file_name
   1:1  │[call-i]
   1:1  │  a
   1:2  │  !=
   1:4  │  2

and those you cannot:

julia> (+=)(a,2)
ERROR: ParseError:
(+=)(a,2)
#└┘ ── invalid identifier

julia> JS.parse(JS.SyntaxNode, "a+=2")
line:col│ tree                                   │ file_name
   1:1  │[+=]
   1:1  │  a
   1:4  │  2

The former are always normalized to the call expression, even when used as an infix operator, as you can see above. The latter have the operator as their head instead. Whether they are multi-operand operators or not is an orthogonal question to whether they are an is_infix_op_call.

Every operator that gets parsed as a call expression has (may have) an associated function of the same name (otherwise that parsing would be invalid after all) and can be overloaded. This is not the case for non-call infix operators, which are either fixed syntactic constructs (e.g. ->, which just defines an anonymous function) or "compound operators", which get lowered to e.g. an assignment and a function call (a+=2 is equivalent to a = a + 2 after lowering, which you can check with by comparing Meta.lower(Main, Meta.parse("a+=2")) to Meta.lower(Main, Meta.parse("a=a+2"))).

Can I ask what you're trying to accomplish here? It's possible that e.g. creating a custom syntax tree will make the kind of analysis you're looking for much easier.

---

I can't think of a postfix one right now, though

julia> JS.parse(JS.SyntaxNode, "a'")
line:col│ tree                                   │ file_name
   1:1  │[call-post]
   1:1  │  a
   1:2  │  '

function is_infix_op_call(node::TreeType)
    return JS.is_infix_op_call(node) ||
           kind(node) in KSet"== === = != !== && || += -= *= /= \= &= |= ->"
end

Looks like you're trying to implement something like is_infix_op here. You might just want JS.is_infix_op_call(node) || JS.is_operator(node) here?

(I find it confusing that the single operator in the tree is in second position, not first).

As per this comment, that's to match source order (not entirely convinced by that argument tbh). Note that you'll get the expected order when parsing as Expr, which does further normalization (at the cost of discarding information -- you can't distinguish 1!=2 from (!=)(1,2) at that point).

And what is the rule to know which is which?

is_infix_op_call is the answer :) The heuristic for humans is "is it valid in infix position and can I define an overload for it?".

[bellon-tiobe]

Thanks, Sebastian.

What I am doing is writing a code checker for Julia, to enforce a coding standard and best practices (which I don't decide). I would think that creating a custom syntax tree is more work, because the Julia compiler doesn't have an API to hook custom code to its production rules. Am I wrong?

[pfitzseb]

If said code checker is only supposed to work on syntax without any semantic understanding (of e.g. scopes), then no, it wouldn't be a lot more work. JuliaSyntax itself provides a few syntax tree types (syntax trees, green trees, and Expr trees, kinda). Whether or not that's actually going to be useful for you I don't know though.

Anyways, coming back to the original question: does is_infix_op(node) = JS.is_infix_op_call(node) || JS.is_operator(node) work for you?

[bellon-tiobe]

I would guess that JS.is_operator returns true for prefix and postfix operators, too, so that wouldn't be what I want. Is that the case? I imagine that I have to figure whether an operator is used as prefix or infix from the shape of the syntax tree.

Anyway, we can close this issue report, since there is a reason for how the predicate is_infix_op_call operates.

[pfitzseb]

No. AFAICT is_operator, is_infix_op_call, is_prefix_call, is_prefix_op_call, is_postfix_op_call are all mutually exclusive.