yes; I've seen fancier* (traditional tree) tty output, but my ~16-line tree dump just provides a quick-n-dirty AST walk, eg.

  (/)
  ├─(+-)
  │ ├─(-)
  │ │ └─b
  │ └─(sqrt)
  │   └─(-)
  │     ├─(*)
  │     │ ├─b
  │     │ └─b
  │     └─(*)
  │       ├─(*)
  │       │ ├─4
  │       │ └─a
  │       └─c
  └─(*)
    ├─2
    └─a

* for DAGs and fancy output I normally produce .dot and run through graphviz.

Thank you. I think I'll bite the bullet and write my own AST dumper too. Got to love those line-drawing chars.

P.S. graphviz/dot = same here.

QnD AST dumpers are grand. Have fun!

some further directions I've been nerd-sniped:

(a) color-coding to make the labels stand out from the lines (clumsily indicated supra by putting node labels in parens)

(b) only expanding N levels of AST (leaving everything deeper as "...")

now that we're discussing it; maybe I should revisit and add:

(a) repetition detection for primitive DAGs? (detection is easy; presentation, however...)

(b) instead of bottoming out with "...", label with the reconstituted expression. eg. N=3:

  (/)
  ├─(+-)
  │ ├─(-)
  │ │ └─b
  │ └─(sqrt)
  │   └─b*b-4*a*c
  └─(*)
    ├─2
    └─a

?

PS: on the birthday run front, that's how a friend got into ultramarathoning :-P

Great! I like the idea of the depth limit as well as how you inlined part of the quadratic equation, I'd like to have a flag/switch for something like that too, e.g. maybe print out the condition part of a while statement inline.

As for DAG's. I'm trying to pick up a semi-abandoned side project, in it there's this 50% complete (& buggy) function to turn basic-blocks into DAG's for analysis. Once I get it work, it'd be nice to have some better way to visualize its output than just printing out a list of labels & edges.

PS: LOL!! Good for your friend, hopefully still going strong :) I'll just say that I'm in my 50's and things are starting to get interesting. Then again there's Gene Dykes (The ultrageezer, https://twitter.com/theultrageezer) there's hope... Have no wish to become as fast as he is, as long as I can keep running ;)

For DAGs, I'm guessing it's better to use some sort of let/where notation, because doing the APL/Lisp Reader thing of naming a defining use and then referring to it elsewhere involves an arbitrary choice of which instance to use as the def'n.

eg. for a mean of the first few even nats:

  (/)
  ├─(sum)
  │ └─(by)
  │   ├─(,..)
  │   │ ├─0
  │   │ └─8
  │   └─2
  └─(len) 
    └─(by)
      ├─(,..)
      │ ├─0
      │ └─8
      └─2

I think I'd prefer:

  (/)        #0:(by)
  ├─(sum)    ├─(,..)
  │ └─#0     │ ├─0
  └─(len)    │ └─8
    └─#0     └─2

to:

  (/)
  ├─(sum)
  │ └─#0:(by)
  │   ├─(,..)
  │   │ ├─0
  │   │ └─8
  │   └─2
  └─(len) 
    └─#0

although there's still an arbitrary decision to make as to how to order references when there's more than one dup, so maybe picking an encounter order as in the latter is as good as it gets?

Good one, should stay pretty readable for non-trivial graphs. And I agree, as-found-on-traversal ordering is likely as good as any other.

I guess the Dream DAG would be some sort interactive zoom&click to expand thing, probably beyond my use case (and certainly beyond my console programming knowledge!)