Color type parameter nesting in show

[rafaqz]

Its common for single types to take up 5, 10, and even 100 lines in the REPL. But its hard to extract information from a wall of flat, same-colored text.

As an alternative to #50884, it may make more sense to color the depth of nesting in types, so type parameters are given the next color in sequence from the current type. It would have a similar result for MethodError and at the same time make all complicated types easier to read.

If we cycle say four colors, we could distinguish four levels of nesting, and subsequent nested layers would be clearly internal, while using the same colors. This seems harder to achieve than #50884, but I can PR if people like this idea.

[Seelengrab]

I think that's going to be confusing with the per-module colors we currently print in stacktraces. People may assume the colors between these two (the message in a MethodError and the stacktrace following it) are correlated.

[rafaqz]

What do you mean by per-module colors? But yes I just hacked a demo and its a bit too much.

And still, types are pretty hard read currently, making that easier would make debugging a lot more efficient.

[Seelengrab]

I'm talking about #45069.

I do agree that large/deeply nested types are hard to parse visually. I don't think adding more colors to that is the solution though. That'll IMO just end up like a colorful mosaic, too noisy to parse visually.

[timholy]

I think the best way to solve this problem is with something like https://github.com/JuliaCollections/FoldingTrees.jl. I think it would be a small enough addition that we could perhaps add a foldable parametric type-printer directly to that package, but it might be better as a separate package.

[rafaqz]

How would FoldingTrees.jl or similar packages help with reading the types in error output or various other places we print them in the REPL?

Do you mean just to manually inspect one specific type that you have in a variable?

[timholy]

Right. And since we have err, it's just an ergonomics issue to capture a specific signature (or portion of a signature) from a specific frame and feed it into a future TypeInspector.jl package.