That’s not quite the whole story.
Regarding your examples 1 and 2: To the parser, .=> is no different from any other infix operator, which just happens to have the same precedence as =>. All the add-dots function you see at the top of julia-syntax.jl does, is add both op and .op to the parser’s list of valid operators. The parser doesn’t have any clue that these are broadcasted calls, to it, they are just regular call expressions.
(=>).(a, b) is parsed as (|.| => (tuple a b)), which is pretty much treated the same as getproperty, like a.b from the parser’s perspective.
Since just a couple of days ago on master, there’s also a 4th case, namely (.=>)(a, b), because to enable standalone .op syntax to represent the broadcasted version operators as in map(.*, a, b), this is parsed as (call (|.| =>) a b), i.e. a function call expression to the expression (|.| =>).
This means, that none of the actually interesting stuff about broadcasting syntax, like broadcast fusion or fused inplace broadcasts is actually handled by the parser, which is exactly as it should be, since the parser’s job is to just produce a tree representation of directly what you wrote and not really try to interpret what this means functionally. All of the cases above are then handled in expand-fuse-broadcast in julia-syntax.jl, as you wrote above, to actually implement all the broadcasting semantics and lowering to the proper Base functions in Base.Broadcast.
6 Likes