better general object printing

[StefanKarpinski]

Goals:

• printing circular structures
• printing objects with type annotations
• printing objects structurally instead of "pretty printing" them

It should probably be possible to switch between different printing modes in the repl. It's especially often quite handy to have type annotations in the repl.

[JeffBezanson]

Printing arrays nicely and printing circular references are two separate issues, and the first one is much more important.

[StefanKarpinski]

Good point. I'll make a separate issue for array printing.

[JeffBezanson]

Do we really need printing of circular structures for 1.0?
How will printing type annotations work?
One way I can see to handle cases like these is to have separate methods, show and show_impl, where the first one is the one you always call, and it takes care of checking for cycles and/or printing type annotations, and the second on is the one that types actually implement. Do we want something like that?
What do you mean by printing structurally instead of pretty printing?
In general I don't like "modes"; I prefer having dump, show, show_all, etc.

[StefanKarpinski]

Do we really need printing of circular structures for 1.0?

Strictly, no. But not being able to print self-referential structures is kind of amateur hour. This is really not all that hard, you just need to keep a hash of everything you've seen, and maybe optimize by not bothering for things that can't be self-referential. Can we have a test for types that may be self-referential?

How will printing type annotations work?

I was thinking that showing them as "Hello, world."::ASCIIString would do.

One way I can see to handle cases like these is to have separate methods, show and show_impl, where the first one is the one you always call, and it takes care of checking for cycles and/or printing type annotations, and the second on is the one that types actually implement. Do we want something like that?

Maybe, that could be a good way to go. Why separate them? Because of the annoying machinery of taking care of circular stuff, etc.?

What do you mean by printing structurally instead of pretty printing?

Basically, what dump() does.

In general I don't like "modes"; I prefer having dump, show, show_all, etc.

That's fine. The only "mode" I might actually want would be adding type annotations to all things that are shown. But maybe people just have to do dump() to see that. Another thing you can imagine is that people might want to always see what the sizes of arrays are, which we currently don't show at all. Not sure.

[JeffBezanson]

If we have only one method, where do we handle checking for cycles and type annotations?

It seems dump needs some work. It calls show on object fields; should it call dump instead?

[StefanKarpinski]

I wrote dump(), as I recall, to inspect Cmd objects when I was building all of that stuff, and since they are highly circular, calling dump() recursively would have caused a stack overflow. Having dump() call show on its parts avoided the recursion. But yes, it really should be recursive — but then we have to handle printing circular structures correctly.

You may be right that it's impossible to only have one method.

[JeffBezanson]

If we have dump do all its own printing of potentially self-referential objects, then that would be an easy way to handle cycles. Of course then you'd have to call dump explicitly.

[ViralBShah]

Perhaps some of this is 1.0, but I really can't tell how important this is. Someone should triage it.

[StefanKarpinski]

I think this is fairly important. We need to display objects well. That's a basic part of the usability of the system that every user will encounter and it will make an impression. Remember how pissed Jeff was that he could inspect any objects in OCaml? We're much better than that, but we want to not just be better than OCaml.