3 ms·

If the source file format for the language is not stored as plain text but it's already in a tree like file format then no, it's not just syntax highlighting bu

by leni536 12y ago

If the source file format for the language is not stored as plain text but it's already in a tree like file format then no, it's not just syntax highlighting but the natural way to handle this file. I could imagine a source file format where the nodes have different types for different literals. There would be much less parsing problem than parsing plain text, of course it would need a special editor.

__david__ 12y ago
Already in a tree format like lisp? Or some binary structure? Even if it's some fancy binary format, it's still going to have to be parsed by the compiler and the editor (and thoroughly checked for syntax errors), making it no better than what we already have now (just different). And unless those node types are "green round-rectangle", then I posit that it's still syntax highlighting, since the editor is deciding how to display "string node".
- zeckalpha 12y ago
  Or JSON. Images could be even be embedded using base64.
- ksrm 12y ago
  Wouldn't storing and editing source code as an AST make a lot of syntax errors impossible?
  - __david__ 12y ago
    User-created syntax errors, possibly. But it can't completely eliminate them: 5 ↤ "hello" Now you could argue that the editor might detect that and not allow it, but if your abstract syntax tree data structure can support it, then you will be handed it at some point and so you should detect it. But more importantly, the abstract tree itself has to be stored. Whatever the format (binary or otherwise), that has to be checked, too (unless you want buffer overflows or code execution exploits in your compiler/editor). All in all, it sounds like the same stuff compilers already have to deal with, so I don't think it wouldn't be a win there.
the_af 12y ago
Needing a special editor is probably an insurmountable problem. There's a reason why textual representation of source code is so convenient. Also, there must be a better example than quotes and strings for this "visual" representation to make sense. There is nothing hard about either reading or typing them. It's not even a particularly nerdy concept; readers and writers everywhere know how to handle quotes. Quotes are already visual by the way. They simply aren't color-based. Which probably makes colorblind readers glad.

by leni536 12y ago

__david__ 12y ago

Already in a tree format like lisp? Or some binary structure? Even if it's some fancy binary format, it's still going to have to be parsed by the compiler and the editor (and thoroughly checked for syntax errors), making it no better than what we already have now (just different). And unless those node types are "green round-rectangle", then I posit that it's still syntax highlighting, since the editor is deciding how to display "string node".

zeckalpha 12y ago
Or JSON. Images could be even be embedded using base64.
ksrm 12y ago
Wouldn't storing and editing source code as an AST make a lot of syntax errors impossible?
- __david__ 12y ago
  User-created syntax errors, possibly. But it can't completely eliminate them: 5 ↤ "hello" Now you could argue that the editor might detect that and not allow it, but if your abstract syntax tree data structure can support it, then you will be handed it at some point and so you should detect it. But more importantly, the abstract tree itself has to be stored. Whatever the format (binary or otherwise), that has to be checked, too (unless you want buffer overflows or code execution exploits in your compiler/editor). All in all, it sounds like the same stuff compilers already have to deal with, so I don't think it wouldn't be a win there.

the_af 12y ago

Needing a special editor is probably an insurmountable problem. There's a reason why textual representation of source code is so convenient. Also, there must be a better example than quotes and strings for this "visual" representation to make sense. There is nothing hard about either reading or typing them. It's not even a particularly nerdy concept; readers and writers everywhere know how to handle quotes. Quotes are already visual by the way. They simply aren't color-based. Which probably makes colorblind readers glad.