I'm sorry I haven't commented on this; I somehow failed to see it come in. I think this is an intriguing idea. I'm not opposed to it, but I am concerned about the potential for a profusion of different tree drawing routines. Does it really make sense to put this in Data.Tree, or somewhere else? I think the best way to answer that question would be for you to send a proposal to libraries@haskell.org and see what the community thinks.

@m-renaud I think this is probably the best example we've seen so far of something that might go in a containers-extra package. It's obviously useful, and it almost as obviously doesn't belong in containers.

I'm a bit unsure what to do about this PR.

On first sight this does seem like an improvement on the existing ASCII drawing functions – it's more polished and more compact, and therefore better suited to visualizing large trees.

I'm also not so concerned about increasing the API size – Data.Tree is a tiny module and the drawing functions are a very specialized corner of that API. I'd be more worried about adding another unfold* variant.

I frankly don't know who actually uses Data.Tree, but I think that any users would find this very useful.

@treeowl

it almost as obviously doesn't belong in containers

Do you still think so? Can you say more about your reasoning?

Also, @paolino, are you still interested at all in this PR?

My reasoning is that it's a data structure library, not a data structure visualization library. But my resistance has softened. I would want to try to gauge community sense by asking the libraries list though; that's the containers tradition .

I suppose you would prefer that the existing ASCII drawing functions were never added and are only kept for backwards compat?

@3noch, probably. But then again, these things can be very helpful for people trying to use the package, so I'm of two minds. Happy to let the community decide this one.

I frankly don't know who actually uses Data.Tree

Just a data point: I do, and precisely for the ASCII art.

Part of an auto-grader (https://gitlab.imn.htwk-leipzig.de/autotool/all0/ )
it sometimes prints derivation trees w.r.t. CF grammars and such.
Yes, since we ultimately output HTML, we can also do inline (SVG, PNG) graphics, but sometimes we don't, since the ASCII stuff is good enough - and students should learn to abstract anyway ...