make printing of UnionAll typevars shorter

[stev47]

fixes #34887

typevars with gensym symbols will now be printed inlined for UnionAll type arguments if their type bounds allow to do so (i.e. <:UB or >:LB).
typevars with named symbols are printed as before since they are assumed to carry meaning and thus might be helpful.

Before:

julia> Ref{<:Any}
Ref{var"#s2"} where var"#s2"
julia> Ref{<:Ref{<:Ref}}
Ref{var"#s1"} where var"#s1"<:(Ref{var"#s2"} where var"#s2"<:Ref)

After:

julia> Ref{<:Any}
Ref
julia> Ref{<:Ref{<:Ref}}
Ref{<:Ref{<:Ref}}

[JeffBezanson]

This is a great improvement, thanks for working on this. The difficulty is that the short-form syntax only works for one level of nesting. For example this PR gives

julia> T = TypeVar(gensym(),Integer);

julia> UnionAll(T,Ref{Ref{T}})
Ref{Ref{<:Integer}}

which is not correct; in that case the current output needs to be used.

[stev47]

The difficulty is that the short-form syntax only works for one level of nesting.

Thanks, then I assume you also care about the order of gensyms within one level? I.e. `Pair{<:Any,T}` vs `Pair{T,<:Any}` for gensym typevar `T<:Any`: only one of those can then be printed as `Pair{<:Any,<:Any}`, since the parser seems to assign them in fixed order. This could get a bit ugly. I need to figure out exactly how the parser assigns the gensyms and how it creates the unionall hierarchy in order to produce the inverse of that. I'll think about it.

[JeffBezanson]

Yes, that's a good point. Pair{<:Any,<:Any} creates the structure Pair{A,B} where B where A, so it has to match that. The variable also can only occur once, for example Pair{T,T} where T (where T is a gensym) can't use the special printing.

Anyway you can probably tell why this hasn't been implemented already :)

[stev47]

next try:

• unionall printing now populates a dict to manage duplicates and named typevars
• fixed misuse of :unionall_env => tv for just displaying the typevar plainly in a few places
• :compact => true now also shortens named typevars

[stev47]

tester_macos64 failure seems unrelated

[JeffBezanson]

Wow, this is really impressive! As far as I can tell it works correctly. Just amazing how difficult this is to implement.

• It would be good to document the meanings of the associated IOContext keys. When there was just one it was pretty clear, but with 3 it will be significantly harder for maintainers to see what's going on and which one they should use.
• It's cool that this detects that Pair{<:Any,<:Any} is equal to Pair and displays it like that, but I wonder if it might be confusing. Would be good to get a couple opinions on that.

[StefanKarpinski]

• It's cool that this detects that Pair{<:Any,<:Any} is equal to Pair and displays it like that, but I wonder if it might be confusing. Would be good to get a couple opinions on that.

FWIW, I like it.

[stev47]

I added some comments explaining the keys. If one was to touch the method printing stuff too, simplifying the logic a bit might be possible, but otherwise there are just too many cornercases making it difficult.

Does isgensym(::Symbol) qualify for public api? I was surprised it wasn't available.

[JeffBezanson]

Here is a small bug:

julia> struct P{A,B<:Integer} end

julia> P{Int,<:Any}
P{Int64}

julia> P{Int64}
P{Int64,B} where B<:Integer

Similarly this quasi-bug where the input and output forms are swapped:

julia> show(IOContext(stdout,:compact=>true), Pair{Int64,<:Any})
Pair{Int64}
julia> show(IOContext(stdout,:compact=>true), Pair{Int64})
Pair{Int64,<:Any}

It would be ok to print both as Pair{Int64} or as Pair{Int64,<:Any}. But to use T{Int64}, we have to check that the bounds of the second typevar match the original typevar in T, or to make it simpler we could just check that it's the same === typevar as in the original.

I also think this doesn't need to depend on :compact. I would just use the most compact form all the time.

A future improvement would be to add support for Unions:

julia> Union{Int,<:Any}
Union{Int64, var"#s2"} where var"#s2"

but that can be done in a later PR.

[stev47]

Changes:

• fixed typevar elision with non-trivial typevar constraints
• fixed dependent typevar printing Pair{A,<:A} where A
• typevar printing is now independent of :compact

Since e.g. Complex != Complex{<:Any} because of the typevar constraint, I'm still hesitant to print them the same way though, since that would violate reparsability to equal typevars.
With this PR you would currently have:

julia> Complex{<:Any}
Complex{<:Any}
julia> Complex{<:Real}
Complex
julia> Complex{<:Integer}
Complex{<:Integer}

which is fully reparsable.

Parametric type aliases might still be somewhat ugly:

julia> NTuple{2,<:Int}
Tuple{var"#s141",var"#s141"} where var"#s141"<:Int64

But finding the shortest alias representation in general is probably over-the-top, so that is left for the future.

[JeffBezanson]

I'm still hesitant to print them the same way though, since that would violate reparsability to equal typevars.

But finding the shortest alias representation in general is probably over-the-top

Fully agree with both; the first priority is to print everything correctly, and we don't need every possible improvement at once.

[JeffBezanson]

I tried to resolve the conflicts but I'm not sure it will work. Let's see what happens.

[JeffBezanson]

Ok, show_datatype needs to be re-indented with an extra end removed, and the new typealias-showing code needs to be updated to use the new IOContext keys. For example

julia> Vector{Vector{<:Any}}
Vector{Vector{<:Any} where var"#s1"} (alias for Array{Array{<:Any, 1}, 1})

[stev47]

Thanks, I almost forgot about this.
Unfortunately it is a bit more complicated now since type aliases can mess around with typevar elision by reordering, consider:

struct A{T,S} end
const B{T,S} = A{S,T}
show(B) # previously showed `A{<:Any,T} where T`, now needs to know about `B` to elide typevars when printing

This small example is trivial to fix but the proper solution would need to build the fully recursed typealias representation before printing (another IOContext key?), then apply my hierarchic typevar counting/elision and only after that print recursively.

[JeffBezanson]

Yes, you're right. Sorry to do that to you. This PR is a great piece of work. We merged the typealias printing first since in some common cases it reduces the amount of output very drastically.

[stev47]

superseeded by #39395