I've been thinking about this constantly for the last 2-3 years. I'm working on something which might lead to this.
What I've concluded, is that we don't have a good representation for a general purpose tree editor to work on. Roughly speaking, S-expressions are just a bit too simple, and XML is way too complicated.
General purpose plain text editors work so well because we've agreed on a common representation (more or less), which is easy for text. But as soon as you want to move to useful, common tree-structures, you have to agree on both representation and semantics, which makes it much harder.
One challenge we need to solve is - what level do you want to work on? Let's say you're working on some code. You may want to treat functions and blocks as a tree structure, but you want to treat simple mathematical expressions as text. Where this threshold is, is entirely context-dependent. The editor needs to understand the language and be able to expand text into its tree structure, or collapse the tree into its text representation, at any node in the tree.
This implies that we need to agree on a common format for defining the conversion (parsing and generating) between text and trees. We'd probably also need a package system which contains common definitions for all major languages.
I've also been thinking about this for about as long (read this same article about 2-3 years ago), and came to pretty much the same conclusion. I actually think defining the grammar for turning text into a tree is likely to be the easy part, compared with building the editor itself.
That said, during my research I ran across an ancient Usenet thread from 1989[1]. In it, the OP asks:
> Should the language designers be making work for the language-oriented editor designers or should the language-oriented editor designers be making work for the language designers?
(The thread rapidly devolves into an all out flame war about whether or not C can be considered to be context-free)
Lisp feels like a language designed specifically to make a language-oriented editor designer happy, but most other popular languages fail the context-free test one way or another, thus making them difficult to define good grammars for. The problem seems to be that historically the language designers have far outnumbered the language-oriented editor designers.
Back in '84 I was an undergrad at Boston University, doing an independent study with one of the business professors, Dr. Fedoritz, on a "next generation spreadsheet" that was to incorporate a cell-less freeform tree structure to represent Frames of Reference. Operating under the business school, we were working on advanced interfaces for financial professionals. The project was called a Frame Based Knowledge Representation System, with each node being a collection of data, with two special data types, one called a "frame" that contains logic and references to the other fields of the node, and one called a "reference" that pointed to a "frame" of some other node. All very basic, as the end-users were not programmers but financial analysts. Due to the freeform intended usage, the UI was on a vector monitor (like the old Asteroids arcade game), and end-users were trained to use the system as a collection of notes they can freeform write anywhere about their job, with little formulas to calculate things within a note and between other notes. It was explained to be like a combination notepad and spreadsheet. And it made a lot of sense to the end-users; they quickly got elaborate with their logic. The UI got zooming capabilities so actively edited or evaluated nodes would scale up while others shrank down, the end-users kept asking for more sophisticated features, and it really looked like we were on to something BIG. During an evaluation of the project with other professors, one of them asked "Once you've completed these requested features from your financial analysts, haven't you recreated just another programming language? The UI is unique, but I'm just seeing an interpreted language and a metaphor for programming that works with your finance end-users." ...And he was right.
I turned the project into another independent study and created a 3D animation language. About a decade later, I was introduced to the first feature film compositor centered around the GPU, called Shake, and it's node layout looked creepily familiar to how the Frame Knowledge System was when I last used it...
You should look at JetBrains MPS, as should everyone posting on this thread. Because MPS has been in development for over 10 years as far as I know, and has attacked and solved a huge number of the issues you raise here and many more too (e.g. how to integrate non-text based programming with version control).
While we might have some common idea what is text, we definitely not have common semantics! The resulting situation isn't so much different from trees.
And what do you mean by "s-expressions just too simple"? Isn't simplicity something to strive for?
> While we might have some common idea what is text, we definitely not have common semantics!
Funny, that makes me think of the new Wikitext editor that the Wikimedia Foundation is developing. [1]
They are using the previous Visual editor infrastructure, and they are having problems because features that make sense for a rich text editor are creeping into the plain-text code editor (such as unwanted copy-pasting of styling code).
> And what do you mean by "s-expressions just too simple"? Isn't simplicity something to strive for?
I should stress "a bit". Actually, looking closer at s-expressions right now (I was writing based on what I remembered), I'd like to flip that statement. S-expressions are just a bit more complex than what I have in mind. Or alternately: they're equivalent under some trivial transformation.
It depends on how you look at things - there are supposedly many different implementations of s-expressions, which support different fundamental data types. The basic idea is simpler. There are no fundamental data types, just nodes. For example a 'bit' is a node which can contain one of two child nodes ('one' or 'zero'). Any tree which represents data in memory on a computer can be expanded down to a collection of bits. Though in a text representation or tree editor the user will generally have collapsed the tree such that they don't see individual bits.
What I have in mind could look more complex than s-expression in a different context though: the text file representation of the trees may have more syntactic sugar than s-expressions in lisp.
The representation isn't significantly different, but the focus is. I'm focusing more on things related to type theory, schemas, how to represent patches/diffs, standardizing parsing/generation and other transforms, etc.
I have reread your text several times, and don't get it. What do you gain by having no fundamental datatypes, only bits? What syntactical sugar is not expressible by s-expression + transformation rules?
I am working on something like that too, and I'm completely fine with symbols (with their arbitrary definition by lisp and user) being the fundamental elements.
> What do you gain by having no fundamental datatypes, only bits?
I'd say what you gain is reusability, mostly. When you impose a datatype on data, it comes with a series of constraints and expectations, so you can only use the data in the ways prescribed by its type.
If the data doesn't have attached a type of is own, you can use it in different ways at different contexts - this can be valuable for data transformation processes, such as compilation or system interfaces. I suppose you could get the same effect by casting the data to a new type when you change it to a new context.
I've read a bunch about applying semiotics theory to programming, and changing the meaning of the symbols "on the go" is closer to the way we think (inferring meanings from the signs adequate to the current context) than the old mathematical approach of "every datum has one well-defined type, and only one".
You must have read about Urbit, right? Their VM's underlying language/bytecode/thing, Nock, is based on nested pairs of natural numbers, which is perhaps only slightly less unwieldy than operating on single bits.
PS, if you're as enthusiastic about this idea as I am, we should talk, can I email you?
I think it could be neat if the spec of the s-exp was read from local hints rather than top-down prescription. You could show a color picker for color argument to a function etc. clojure.spec seems a cool tool.
>What I've concluded, is that we don't have a good representation for a general purpose tree editor to work on. Roughly speaking, S-expressions are just a bit too simple, and XML is way too complicated.
I was wrong about S-expressions. S-expressions are roughly the right complexity, or even a bit too complex, depending on how you look at it.
JSON is way too complex. JSONS assumes that you have an object/record structure (labels and values), and gives you both objects and arrays with which to build tree structures.
JSON is one of the most dominant tree-data formats on the web because of the awesome balance it has between complexity and simplicity. JSON fits the bill nicely.
Actually... it's one of the most dominant tree-data formats on the web because you don't have to bundle a parser with your client and then figure out the idiosyncrasies between your serialisation model and your language's object model, the browser gives you one for free and JSON is your language's object model. It's a lot more fiddly to deal with in languages which don't have a K/V map as the primary object model.
I think what you're describing almost exists for C++ in the form of libclang. Editors really prize uniformity and predictability, to give users a comfortable experience, which is why I think libclang is so unwieldy if you try to integrate it into an editor fully—I tried with emacs once. So, despite all the massive effort put into clang, it gets incorporated piecemeal, one IDE feature at a time.
What I've concluded, is that we don't have a good representation for a general purpose tree editor to work on. Roughly speaking, S-expressions are just a bit too simple, and XML is way too complicated.
General purpose plain text editors work so well because we've agreed on a common representation (more or less), which is easy for text. But as soon as you want to move to useful, common tree-structures, you have to agree on both representation and semantics, which makes it much harder.
One challenge we need to solve is - what level do you want to work on? Let's say you're working on some code. You may want to treat functions and blocks as a tree structure, but you want to treat simple mathematical expressions as text. Where this threshold is, is entirely context-dependent. The editor needs to understand the language and be able to expand text into its tree structure, or collapse the tree into its text representation, at any node in the tree.
This implies that we need to agree on a common format for defining the conversion (parsing and generating) between text and trees. We'd probably also need a package system which contains common definitions for all major languages.