∪ doesn't parse as expected

General Usage
1 
julia> 1..2 ∪ 3..5
ERROR: syntax: extra token ".." after end of expression
Stacktrace:
 [1] top-level scope
   @ none:1

That’s a bummer. I was hoping to use this syntax inside a macro expansion, but it doesn’t even parse. What are the alternatives? Any good unicode to recommend?

2

∪ isn’t the problem, .. is.

julia> (1:2) ∪ (3:5)
5-element Vector{Int64}:
 1
 2
 3
 4
 5
3

Right, but in terms of “I want to offer appealing syntax to my macro users”, having to add parentheses is a downer.

4

I don’t follow you. Both examples work with parentheses and don’t work without them, so in this respect : and .. behave in the exact same way.

5

Yes. Both are the same, both need parentheses, both suck :slight_smile: Is there any operator which looks better and whose precedence makes it work without parens? I looked at the operator list, and 1..2 || 3..4 works, but it has other problems.

I think this is probably unsolvable…

6

You want something on this line:

julia> const ⫫ = ∪
union (generic function with 5 methods)

julia> 1:2 ⫫ 3:4
4-element Vector{Int64}:
 1
 2
 3
 4

julia> :(1:2 ⫫ 3:4).args
3-element Vector{Any}:
 :⫫
 :(1:2)
 :(3:4)
4 Likes
7

Is your desired syntax simple enough to edit the text before standard parsing? A macro can take in a String, and such macros have syntactic sugar for non-standard string literals. I’m imagining it’d be written like setop"1..2 ∪ 3..5" and the String changed to "(1:2) ∪ (3:5)" before parseing.

8

Having a macro that parses differently from regular Julia code would be confusing, but it does seem like the Julia operator precedence is kinda bad here.

2 Likes
9

Only tangentially related since it doesn’t actually solve the original request, but I’ve been wondering what Julia would look like if it had an operator precedence system like Better operator precedence.

10

Yeah, Operator Precedence: We can do better • The Adamant Programming Language Blog

Fortress had it too JuliaCon 2016 (Keynote) | Fortress Features and Lessons Learned | Guy Steele - YouTube

1 Like
11

Personally, I like parentheses.

With the exception of the really common operators that have the same precedence in every language, I think that code is more readable with parentheses than without.

(My editor is colouring matching parentheses, which helps a lot for readability. But I also liked them before it had that feature.)

Conversely, I think a language that allowed the user to remove parentheses by re-defining the order of precedence would be very hard to read for me.

1 Like
12

It must be that I’m running an older version–I still get an error when adding parentheses in the original:

julia> (1..2) ∪ (3..5)
ERROR: UndefVarError: .. not defined
Stacktrace:
 [1] top-level scope
   @ REPL[3]:1
13

I believe this syntax comes from Intervals.jl (but could be any custom defintion for ..)

1 Like
14

It’s for a macro, so the important thing is for it to parse as quoted.

julia> :((1..2) ∪ (3..5))
:((1 .. 2) ∪ (3 .. 5))
2 Likes