better general object printing about julia HOT 14 CLOSED

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

from julia.

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

from julia.

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.

from julia.

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.

from julia.

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?

from julia.

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.

from julia.

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.

from julia.

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

from julia.

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.

from julia.

@StefanKarpinski bump. do you want to create new issues with the still-relevant parts of this meta-issue and close this?

from julia.

Will do. Leave it open for now.

from julia.

related: #1139 recshow pull request

dump seems pretty good for printing type annotations. do you still want something in-between show and dump?

from julia.

We now have dump, xdump, there's been several more iterations on Arrays/Dicts, and we just merged #3831 which handles circular references. I think this can be closed in favor of any more specific concerns/suggestions going forward. @StefanKarpinski?

from julia.

Since there didn't seem to be any objection to closing this in favor of more specific issues, I'll just do that. One can always reopen ;).

from julia.