Doesn't support Union in an IOContext?

[vtjnash]

julia> print(ttio, Union{Int32,T} where T)
ERROR: TypeTreeIO does not support byte I/O
Stacktrace:
  [1] error(::Type, ::String)
    @ Base ./error.jl:44
  [2] write(s::TypeTreeIO, x::UInt8)
    @ Base ./io.jl:291
  [3] write(io::IOContext{TypeTreeIO}, byte::UInt8)
    @ Base ./io.jl:428
  [4] write(io::IOContext{TypeTreeIO}, c::Char)
    @ Base ./io.jl:739
  [5] print(io::IOContext{TypeTreeIO}, c::Char)
    @ Base ./char.jl:252
  [6] show_delim_array(io::IOContext{TypeTreeIO}, itr::Vector{Any}, op::Char, delim::Char, cl::Char, delim_one::Bool, i1::Int64, l::Int64)
    @ Base ./show.jl:1307
  [7] _show_type(io::IOContext{TypeTreeIO}, x::Type)
    @ Base ./show.jl:968
  [8] show(io::IOContext{TypeTreeIO}, x::Type)
    @ Base ./show.jl:953
  [9] _show_type(io::TypeTreeIO, x::Type)
    @ Base ./show.jl:997
 [10] show(io::TypeTreeIO, x::Type)
    @ Base ./show.jl:953
 [11] print(io::TypeTreeIO, x::Type)
    @ Base ./strings/io.jl:35
 [12] top-level scope
    @ REPL[5]:1

[timholy]

Thanks for the report!

On JuliaLang/julia#49231, any thoughts about whether this or parsing-independent construction method is superior? I'm playing with an approach in the teh/not_io branch of this repo but haven't gotten super-far yet.

[vtjnash]

I had prototyped a version of an IO object that supported semantic annotations during printing in https://github.com/JuliaLang/julia/pull/27430/files#diff-7e4f858605d8e7631cf8ddaf624fd67f8acd65fce49ab3c1b9613ed491290787 and https://github.com/vtjnash/Firelight.jl/blob/master/src/richprint0_6.jl, so I might be slightly biased on that question haha.

[vtjnash]

In the Firelight.jl repo there, I was building an experiment where I wanted it to be both tree-like and text-like. It was a type that was intended to be similar to html, or a templating language for html, where you have plain text, rendered text, and also source information for each character. The goal there was to build a GUI, so that if you clicked on anything, it could give you a reference to that element in the backend representation, and then collapse, fold, expand, navigate to, or re-render any part of it interactively.

[timholy]

So if I'm interpreting you correctly, you like the IO approach? That was my initial expectation; I developed a few doubts when I saw some of the bugs that my early implementations were vulnerable to, but my attempts at the other approach have given me a renewed appreciation of why that's hard, too. In which case maybe the best thing to do is fix the bugs in JuliaLang/julia#49231 and be done with it.

So unless you disagree, I'll probably just proceed with the IO approach and not waste any more time on alternatives.

[vtjnash]

Yes, I liked the IO approach, but I also wanted to modify IO so that it emitted begin/next/end tags for each portion of the objects too so that it could be navigated as a tree too