Why Don't We Have a General-Purpose Tree Editor? (2014)

Re:Why Don't We Have a General-Purpose Tree Editor? (2014) by TeMPOraL on Monday February 06, 2017 @07:16PM (#13585741)

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.

[ Parent | on HN ]

Re:Why Don't We Have a General-Purpose Tree Editor? (2014) by unhammer on Wednesday February 08, 2017 @06:07AM (#13597377)

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 …

[ Parent | on HN ]