The AST of that would still be a tree. AST does not concern itself with the semantics of the language, only its syntax.

Not 100% sure how to interpret this piece of code, but my naive interpretation gives this AST:

  (def f ()
    (let ((x (readline)))
      (g x)))
  
  (def g (x)
    (print x)
    (f))

Writing in Lisp can open one's eyes about the underlying structure of the code.

My point was that "Code editing is tree editing" sounds a bit like if you can understand the syntax tree, you understand what the code does – which isn't true here. Trees don't show the recursion[1], and a tree-view of code (with e.g. folding) might even give a false impression that what's inside one branch is somehow self-contained. Ie. Turing Machines are more expressive than CFG's :-) Not that tree-view's aren't helpful (indentation is important, and editing Lisp with paredit is a real joy), but there's much more to code-editing than tree-manipulation.

[1] Unless your "tree"-view is actually a lazy call-graph …