RFC: "quiet" types for easier-to-read stack traces

[JeffBezanson]

It is fairly common to define types with parameters whose only use is specialization (of code and memory layout), and printing those parameters everywhere can cause excessive noise. One motivating example is https://github.com/SciML/OrdinaryDiffEq.jl/blob/2eb73bed76c31248113fa8f3f05ff2f84448651a/src/integrators/type.jl#L80. The proposed feature here is to put Experimental.@quietparams in a struct declaration, and then printing instances and types within stacktraces will omit parameters, e.g.

julia> struct Foo{A,B,C}
       a::A
       b::B
       c::C
       Base.Experimental.@quietparams
       end

julia> map(error, [Foo((1,2),4,5)])
ERROR: Foo((1, 2), 4, 5)
Stacktrace:
 [1] error(s::Foo{...})
   @ Base ./error.jl:44

In the case of ODEIntegrator, each type can be multiple screens full of text and it is causing quite a problem.

[Keno]

Why does this need a flag in the datatype rather than just having a macro that overrides is_quiet_type for the type in question?

[jw3126]

Could this be spelled:

struct Foo{A,B,C}
       a::A
       b::B
       c::C
end
Base.Experimental.@quietparams Foo

That would for instance allow silencing types you don't own in a debugging session.

[pablosanjose]

This sounds useful.
Feature request: could one choose to silence some parameters and not others?

[timholy]

In case it affects thinking on this issue: I think our issues with type-printing go beyond this special case. Someday I'm planning on investigating whether all parameters in stack traces can initially be printed in "folded" form. Now that we have err we can revisit the stacktrace interactively, so printing in folded form is no longer truly lossy for deep debugging. These plans also vaguely include an interactive REPL mode for incrementally unfolding those parameters. To me this seems like a more comprehensive solution, and thus we might not need to add special language features for special cases that may fairly soon become redundant.

If someone gets excited about this and wants to beat me to the punch, that would be wonderful. But if that doesn't happen, it's on my (long) TODO list.

[antoine-levitt]

FWIW, as a data point in this line of thinking, I've been using https://github.com/BioTurboNick/AbbreviatedStackTraces.jl in the "minimal" mode (one line per frame, with only the function name, without arguments) for a while now, and I very rarely have found the need to have the types of the arguments (or even the argument names).

[vtjnash]

I sort of like Tim's idea, where the REPL (with limited=true IOContext) skips showing the type details, but that logs and other non-interactive contexts continue to show all parameters, and err can access the whole content. This PR otherwise feels mildly hostile to developers, since I can no longer take a user's stacktrace and replicate it in Cthulhu from an arbitrary point to simulate what it was doing wrong.

[JeffBezanson]

I agree it would be much better to have stacktraces in the REPL let you interactively expand type parameters.

[timholy]

We already have FoldingTrees' TreeMenu, how hard can it be? (Famous last words...)

[KristofferC]

Here are two reasonable paths forward (in mu mind):

1. Do something specific for stacktraces (or maybe just limited=true IO. For example, just hide types parameters in stacktraces by default and have err show them with some opt in for showing type parameters by default. I don't think any interactive unfolding of type parameters are needed, either you want to see them or you don't.

2. Do something like showargtype as Tim mentioned in Making stacktraces shorter (reducing the number of frames) #49044 (reply in thread). This would allow package authors to more precisely define how their type should be printed "conveniently". It is up to callers to decide whether to use show or showargtype. However, if everyone (including Base) starts using showargtype it would surely be just as vulnerable to invalidations? But at least things like string interpolation don't add backedges to it.

[timholy]

I'm going to be traveling all next week with very little availability, but if anyone wants to run with this, I just pushed a big head start: https://github.com/timholy/TypeTreesIO.jl. The idea is that whether we print abbreviated type info or have a full UI for folding parameters, it's probably best to have a tree organization of the information that could be printed. For example, if we want to print with a target of no more than 80 characters in the signature, it's probably best to use a homogeneous depth for all arguments and then print anything that's omitted as ....

Feel free to do whatever with that. Contact me by email, discourse, or slack if you're known to me and want an invitation to the repo.

[storopoli]

We are getting lots of feedback from Pumas new users.
Even the advanced coders are overwhelmed by the huge stack traces they get.
So I think that something like this would great benefit not only these users but others as well.