4 ms·

Your representation is certainly valid, but I think those properties (light-weight, intuitive, etc.) apply to your example rather than your representation. For

Your representation is certainly valid, but I think those properties (light-weight, intuitive, etc.) apply to your example rather than your representation. For example, imagine representing the HTML of this Hacker News page in your format; it would be completely unwieldy, and Hacker News is notoriously simple as far as HTML goes. It's clear that this representation is massively space inefficient, since it repeats the vertex labels over and over. It's also massively time inefficient for common operations, like finding the incoming/outgoing edges of a node; these can be seen "at a glance" in some representations, like boxes + arrows, whilst your representation requires traversing the entire set of edges looking for matches. In fact, I can't figure out a sensible way to even write down the vertices in such an example! Even if we invented some arbitrary labelling scheme, e.g. labelling nodes based on their path from the root, or based on their position in a post-order traversal, such labelling schemes would be enough to define the tree on their own! Unfortunately I think this is another case of trying to shoehorn sets into places where they don't belong for no particular reason, as if trees are somehow "less mathematical" than sets. It didn't work for Bertrand Russell, and it doesn't work here ;) > if you want a graphical representation there's always tools like graphviz Graphviz is notoriously messy when it comes to graphs of any nontrivial size, and the existing tooling makes interaction less than ideal (e.g. using home-grown scripts on top of image canvases and hotspots, rather than established interaction methods like a widget toolkit). > Also, I don't understand why a tool to manipulate graphs, rather than just represent them, would be any different than a proof assistant or a theorem prover. I don't see the connection myself. Proof assistants are incredibly picky about what they allow (that's kind of the point ;) ); on the other hand, a tree editor would be used for "fast and loose" cutting, pasting, duplicating, rotating, swapping, etc. of arbitrary sub-trees in arbitrary structures. How would tooling like, say, Coq, help with that?

YeGoblynQueenne 10y ago
>> For example, imagine representing the HTML of this Hacker News page in your format; it would be completely unwieldy, and Hacker News is notoriously simple as far as HTML goes. Well yes, but that's because HTML is a mess, not because graph notation is unwieldy. In any case I don't think it's a good idea to try to program in graph notation, or anything like it. Actually, I think it's a terrible idea. Unless you want to create some kind of help tool for graph theory, I guess. >> Proof assistants are incredibly picky about what they allow (that's kind of the point ;) As are all programming languages. Manipulating graphs, er, graphically, will not give you some sort of magical get-out-of-jail-free card against syntax errors or undefinable behaviour etc. Like, I'm not even sure what the point is here, with the OP. Is it along the lines of "hey, look at graphs, graphs are cool, let's make coding cool with cool graphs"? Or is there some sort of benefit, like expressive power or syntactic clarity, that you don't have with high-level languages already? Why do you need a GUI to an AST? To be honest, the OP looks like a bit of a muddle to me.
- chriswarbo 10y ago
  > Manipulating graphs, er, graphically, will not give you some sort of magical get-out-of-jail-free card against syntax errors or undefinable behaviour etc. It does prevent some errors, like malformed structures. For example, the following Lisp: (defun (square x (* x x)) Or the following C: void square(int x { return x * x; Or the following Ruby: while $i < $num do puts "Inside the loop i = #$i) $i +=1 These sorts of things can occur when manipulating programs at the character level, but they're inexpressible at the level of parse trees/graphs. Balancing parentheses, braces, quotation marks, begin/end, etc. is exactly the sort of task that machines can automate away. The idea of a general tree editor is not to prevent syntax errors, undefined behaviour, etc. because those are properties of specific trees, e.g. the parse trees of C programs. A tree editor just edits trees; it doesn't care what those trees represent (that's why the author mentions a plugin mechanism, like Emacs has different modes for editing files written in different languages). Manipulating programs at the level of parse trees can also be more efficient, less tedious and prevent errors, e.g. see the paredit videos linked in other comments. By analogy, what's the point of a general text editor, when our CPU can already perform arithmetic on bytes? A general text editor doesn't prevent syntax errors, undefined behaviour, etc. Does editing strings of text, rather than numerical bytes, provide expressive power or syntactic clarity that we don't have with high-level languages already? I also don't think the author was asking for something "graphical" or "GUI" per se; their analogy is with text editors (e.g. Emacs and Vi), which are efficient both in their display and their interaction. A general tree editor wouldn't be based around e.g. drag'n'drop of nodes/edges, in the same way that general text editors aren't based around drag'n'drop of glyphs in a grid. General text editors have features for moving to the start/end of a line, for cut/paste up to the next space or linefeed, for highlighting parentheses, for folding/unfolding between sentinel characters, etc. General tree editors would instead have features to move to the root/leaf of a tree, cut/paste sub-terms, fold/unfold expressions, etc. No need to care about the existence of whitespace, linefeeds, indentation, parentheses/delimiters, etc. they can all be handled mechanically.
  - kazinator 10y ago
    We can have editing methods that are character-based, yet which make those kinds of syntax errors impossible. A trivial example of this are input fields which enforce a lexical format. For instance, we can implement an input field for a floating-point number where you simply cannot type some garbage like "1.E". What happens is that you type "1" (so far so good), then then "1." (still good) and then "1.E" (good prefix, but bad). Since it is a good prefix, the "E" is allowed, but the validator automatically inserts some suffix to make it valid, like 0. So you see "E0". The 0 is selected so that the next thing you type will replace it. But if you type some garbage like Z, it will be rejected; at that point you may only type a + or - sign, or a decimal digit.

YeGoblynQueenne 10y ago

>> For example, imagine representing the HTML of this Hacker News page in your format; it would be completely unwieldy, and Hacker News is notoriously simple as far as HTML goes. Well yes, but that's because HTML is a mess, not because graph notation is unwieldy. In any case I don't think it's a good idea to try to program in graph notation, or anything like it. Actually, I think it's a terrible idea. Unless you want to create some kind of help tool for graph theory, I guess. >> Proof assistants are incredibly picky about what they allow (that's kind of the point ;) As are all programming languages. Manipulating graphs, er, graphically, will not give you some sort of magical get-out-of-jail-free card against syntax errors or undefinable behaviour etc. Like, I'm not even sure what the point is here, with the OP. Is it along the lines of "hey, look at graphs, graphs are cool, let's make coding cool with cool graphs"? Or is there some sort of benefit, like expressive power or syntactic clarity, that you don't have with high-level languages already? Why do you need a GUI to an AST? To be honest, the OP looks like a bit of a muddle to me.

chriswarbo 10y ago
> Manipulating graphs, er, graphically, will not give you some sort of magical get-out-of-jail-free card against syntax errors or undefinable behaviour etc. It does prevent some errors, like malformed structures. For example, the following Lisp: (defun (square x (* x x)) Or the following C: void square(int x { return x * x; Or the following Ruby: while $i < $num do puts "Inside the loop i = #$i) $i +=1 These sorts of things can occur when manipulating programs at the character level, but they're inexpressible at the level of parse trees/graphs. Balancing parentheses, braces, quotation marks, begin/end, etc. is exactly the sort of task that machines can automate away. The idea of a general tree editor is not to prevent syntax errors, undefined behaviour, etc. because those are properties of specific trees, e.g. the parse trees of C programs. A tree editor just edits trees; it doesn't care what those trees represent (that's why the author mentions a plugin mechanism, like Emacs has different modes for editing files written in different languages). Manipulating programs at the level of parse trees can also be more efficient, less tedious and prevent errors, e.g. see the paredit videos linked in other comments. By analogy, what's the point of a general text editor, when our CPU can already perform arithmetic on bytes? A general text editor doesn't prevent syntax errors, undefined behaviour, etc. Does editing strings of text, rather than numerical bytes, provide expressive power or syntactic clarity that we don't have with high-level languages already? I also don't think the author was asking for something "graphical" or "GUI" per se; their analogy is with text editors (e.g. Emacs and Vi), which are efficient both in their display and their interaction. A general tree editor wouldn't be based around e.g. drag'n'drop of nodes/edges, in the same way that general text editors aren't based around drag'n'drop of glyphs in a grid. General text editors have features for moving to the start/end of a line, for cut/paste up to the next space or linefeed, for highlighting parentheses, for folding/unfolding between sentinel characters, etc. General tree editors would instead have features to move to the root/leaf of a tree, cut/paste sub-terms, fold/unfold expressions, etc. No need to care about the existence of whitespace, linefeeds, indentation, parentheses/delimiters, etc. they can all be handled mechanically.
- kazinator 10y ago
  We can have editing methods that are character-based, yet which make those kinds of syntax errors impossible. A trivial example of this are input fields which enforce a lexical format. For instance, we can implement an input field for a floating-point number where you simply cannot type some garbage like "1.E". What happens is that you type "1" (so far so good), then then "1." (still good) and then "1.E" (good prefix, but bad). Since it is a good prefix, the "E" is allowed, but the validator automatically inserts some suffix to make it valid, like 0. So you see "E0". The 0 is selected so that the next thing you type will replace it. But if you type some garbage like Z, it will be rejected; at that point you may only type a + or - sign, or a decimal digit.