Proposed alias for union types

Internals & Design
,
141

I think that these packages should stick to the standard Julia syntax (perhaps shortened with … when applicable for heavily parametric types), anything else should be confusing.

Also, with Cthulhu, complex union types are usually exactly what I am looking for, especially if they cause problems. I don’t see the point of making them less obtrusive.

2 Likes
142

If it’s just for debugging one’s own library I think it could be helpful to have a configurable type alias system in Cthulhu’s outputs. Julia’s type system is the best I’ve encountered in any language, but it can admittedly get a bit verbose at times. Especially as some types stretch over the VSCode length limit in the Cthulhu labels and end up missing some information.

If the user could tweak union aliases in Cthulhu, it might also be useful to allow declaration of preferred abbreviations like Float32 → F32, Tuple → Tu, etc, just to make the printouts less verbose. Again, this is just Cthulhu/JET/etc, this is not a suggestion for all of Julia, don’t worry :slightly_smiling_face:

Maybe like

import Cthulhu: type_string

# default used in package:
# type_string(t) = string(t)

# user aliases:
type_string(::Type{Float32}) = "F32"
type_string(::Type{Union{A,B}}) where {A,B} = "(" * type_string(A) * "|" * type_string(B) * ")"
# etc.

which you could toss in your startup.jl

Aside: I’m also curious how, in a startup file, one could override printing globally for Union{A,B} → (A|B)? It’s obviously type piracy and subjective (and I wouldn’t advise for a package to do this) but if you are using infix unions in code anyways, it could be useful to also override printing locally. (Since you would presumably be able to copy-paste the outputs if you’ve already defined that alias on your system).

2 Likes
143

I agree that Cthulhu.jl should use the standard Julia syntax by default, but could provide an option to display types using a less verbose syntax. It might be useful to test proposals that try to simplify the way types are communicated.

While I can understand that Cthulhu.jl and JET.jl deal with more pressing issues, I can imagine that more people would want a simplified syntax as those tools become more popular.

144

I imagine that the best place to start a discussion about this would be an issue at each package.

1 Like
145

:+1:
Allow user to overload printing behavior · Issue #535 · JuliaDebug/Cthulhu.jl · GitHub

Edit: and now a PR here: Create overloadable function for string representations of types by MilesCranmer · Pull Request #537 · JuliaDebug/Cthulhu.jl · GitHub

4 Likes
146 
julia> show(stdout, Union{Int8,UInt8})
Union{Int8, UInt8}

julia> @which show(stdout, Union{Int8,UInt8})
show(io::IO, x::Type)
     @ Base show.jl:953

That leads to _show_type.

This suggests the following code.

julia> Base.show(io::IO, x::Union) = Base.show_delim_array(io, Base.uniontypes(x), '(', " |", ')', false)

julia> Union{Int8,UInt8}
(Int8 | UInt8)

julia> Union{Int8, UInt8, Int16, UInt16}
(Int16 | Int8 | UInt16 | UInt8)

julia> Base.show(io::IO, x::Union) = (Base.show_delim_array(io, Base.uniontypes(x), "|(", ',', ')', false); return)

julia> Union{Int8, UInt8, Int16, UInt16}
|(Int16, Int8, UInt16, UInt8)
4 Likes