Since this project ended, we've have had quite a lot nice development in this front. Biggest highlight maybe is Combobulate for emacs, providing treesitter powered editing. Neovim also has treesitter and some plugins[2] to work with it. My editor of choice, Helix, also has treesitter based commands built-in[3]. All of these afaik have been released after sapling
While it now seems like this mode of using TS/structured editing to extend traditional editors will be the dominant way, I think it still might be useful to keep thinking what an editor that embraces structured editing could look like.
I had reasonable experience with structure editors (worked on one long time ago, for beginner programmers) and at least in their naïve form they are a bloody pain to use, and far slower to get information in than a halfway decent touch typist. It's possible some improvements might make things better, but it's really hard to see. Happy to be proven wrong!
This is one of the hills to climb when learning a lisp. Seasoned lispers don't edit text, or traverse text; they edit and traverse lisp forms (AST nodes). In my experience, vim/neovim work very well for this, due to their notion of "text objects". With a couple of plugins, text objects end up aligned directly with the lisp AST, but even better is that the AST is visual and tangible, since it's encoded in the text.
It makes sense to benefit from this sort of thinking in other languages, but this is just another reminder, to me, of the beauty of lisps.
A fun language idea would be to take the exact semantics of an existing language, like C++, and encode them within a lisp, losslessly. I suspect it would end up quite verbose. However, add in a macro system and then you can start building a DSL around the original language, keeping all the same underlying semantics.
I agree completely; this is why I think a lisp would be a much better scripting language for a text editor than vimscript or lua. Although I use vim at an advanced level, I have never written a plugin for this reason. Emacs offers a much better scripting environment with elisp.
Other commenter mentioned Hy, but what about Clojure? It is a lisp on top of Java, and all of its variants (Clojurescript -> Javascript, etc). Then there's Fennel (Lua) and others I can't remember right now.
Clojure sits on top of the JVM and allows for Java interop, but the language itself does not losslessly encode all of the semantics of Java. Same goes for ClojureScript and the other dialects.
The difference here is that the lisp's AST would need to map 1:1 with its underlying language.
Isn't that a bit what hy (https://hylang.org/) tries to do ? AIUI it is a lisp interacting directly with the AST of Python, allowing seamless interop: Python modules can be used from hy and vice versa, everything is transparent.
I'm not sure if it's doing exactly that, but it looks like it could be! Very neat. It'd be nice to see it for other langs, if Hy proves viability in the approach.
I find this idea interesting, because it's my impression visual programming is generally considered less powerful than textual programming, but it sounds like the described setup where you visually edit an AST could be a sort of middle ground.
I also recommend symex[1]. Although it is more “locked-in” to s-expressions than other solutions (which takes some getting used to at first), I find that for me this is exactly what makes movement feel much more intuitive and editing much more precise.
The one thing I don’t like is that symex depends on so many other plugins (especially Evil, which I am trying to swap out with the more lightweight meow), but this will apparently change soon. They are also working towards support for non-Lisp languages via tree-sitter, but I don’t know how well it works.
I think the core thought in "But Why" kind of gives away the problem this will face. The idea is that you will lose time as you "move between valid programs." A problem, though, is most "valid programs" are still not valid solutions to what you are working on.
Consider, most of us work in rather phonetic languages as we type day to day. Surely it would be easier if we worked instead in languages where you did not have to do this. Let me type only valid sentences as I move from thought to thought. Surely that would be better? Why, then, do we not do that?
Of course, I don't know why. I suspect there is a good deal to inertia style thoughts that explains this. But it is a good hint that the idea that you can break apart from symbols that need more symbols for context to build meaning is not one that really anything has fully converged to.
I think you're thinking about it subtly wrong. A properly built semantic editor won't force you to move between valid programs in that sense. It will be comfortable decomposing programs into fragments.
For example if I decompose the sentence "I press play" into words devoid of context, "I" still pretty much means what it did but "press" could now as easily mean pressing shirts or pressing an advantage, and "play" could be what children do, not the implied "play button".
A good semantic editor for that sentence would allow me to detach the word "play" without losing the context that the meaning is "play button". Similarly a good semantic code editor would let me do something like pull two non-adjacent class methods out of a class and into a clipboard, then drop them into another class. If you did this this with text, the editor would not understand the clipboard content as class methods are (usually) not parseable outside a class.
Symbols are not context free, though. And words being compound symbols means they are heavily dependent on context. Pretty much period.
You can argue that I should be able to copy a method invocation and move it, but I confess I don't even really understand what that would mean or how it would help me. More, you are fixed in a global evaluation sense of the work, now. What if I want to take a formula in code, evaluate its derivative, and then use that for evaluating input? (That is, the exact same code depends on where it is
But, again, my point was not that we can find the reason it doesn't work. I don't know the reason it doesn't work. I don't even know for sure that it can't work. What I do know is that no other communication has distilled to this level of editing. Happy to be proven wrong.
I had meant to edit my post to refer to this all as "a" problem that this idea will face. Specifically that no other editing of anything that I am aware of happens at this level. There are some neat composition tools that can put together some scenes in this way, I think. Such that maybe there is more of a generalization there than I think there is. Seems very unlikely, though.
Now, oddly, I do think software is best made to enable this style of construction for what it controls. Easy example would be a level editor in a video game. That makes surprisingly little sense to do in a symbol based editor, as opposed to a palette based visual editor. Such that I think I'm open to the idea, at some level. Symbol manipulation is just not that level, for most things.
I always think of this when I edit python and my code is indented wrong... not a fan by structuring by indentation, but it doesn't seem to be a problem for most people.
Cards on the table, I'm a lisp fan, so I'm probably the closest you can get to directly editing an AST for my dream program. I /like/ the idea of it. I just don't think it is a holy grail endpoint of program editing.
Oddly, I do think there is something to making sure all of your data has a literal representation in the code, if you can. Such that I do think being able to directly interact with data is huge. I also love when you can symbolically work with programs.
But, yeah, the overwhelming evidence is that this just isn't necessary for things. Both in communication, and in program specification.
Sapling is the first AST editor that works how Ive imagined it could. I'd love to leave all the whitespace wrangling behind and move only between AST nodes in an efficient way. This was a fun editor to try and I think there is something to learn here still to make treesitter editors more powerful/efficient.
A buddy of mine and I wanted to experiment with such a thing back in ~'85. I started by looking at the "elvis" editor code, trying to wrap my head around it, but I didn't really have a clear picture in my head about what a "modal AST editor" would do, just some vague ideas of an editor that operated on parsed syntax (AST wasn't on the horizon for us at that point). I was in HS at the time, and my buddy was working on a masters thesis, I think he was too busy and it was way too big a project for me to handle at that point.
One interesting thing about GPT&cetera is that in order to "cheat" by using it, you need to clearly describe the problem you are trying to solve. If we can get more people to design before coding begins, I think we're going to have a win in any case.
It’s a very interesting space. There are several experimental editors out there - they’re all rough as you might expect, but the possibilities are fun to think about.
I’m building a semi-structured editor for UI - I’ve described it as “vim for designers.” Just as an example of how varied the general idea can be.
I'm worse, I have thought about this many times but never did anything with the idea. My respect for the authors for actually trying to materialize it.
1. Bias. A lot of people think that if good ones haven't been built already, there must be some reason they can't be built
2. You really want the parser to report not just what types of nodes it found at particular locations, but what types of nodes it could have found at that location, because those are the types that will be valid for insertion there. A semantic editor needs to know because it should only be able to create programs that the parser would be able to parse.
3. Extensible parsers: To make a huge number of parsers that exactly match languages, you need to be able to quickly define parsers that are closely related to each other, and what's more the cost of using the derived parser must be closely related to the cost of using the original. Tree-sitter can derive languages at compile-time, but not at runtime leading to three major problems:
- 3.1 Runaway storage costs: the Tree-sitter grammar for JS is ~4mb, and the grammar for TS is ~12 MB and the grammar for TSX is also ~12mb and these grammars have things they shouldn't have in them like Ember's glimmer syntax, because that syntax is too poorly supported to justify paying the costs of copying the JS, TS, and TSX grammars (causing 28MB of new code duplication, in git no less).
- 3.2 Failed semantics: Because the JS runtime grammar is just code copied into the TS runtime grammar, tree-sitter can't distinguish which parts of TS programs are really just plain JS.
- 3.3 Umbrella languages: Because the grammar defines languages that are bigger than what you can actually use, the JS tree-sitter grammar will happily parse JSX even when it's invalid, which is to say a semantic editor would suggest inserting JSX even when it would break your program, which is clearly bad.
Readit News
While it now seems like this mode of using TS/structured editing to extend traditional editors will be the dominant way, I think it still might be useful to keep thinking what an editor that embraces structured editing could look like.
[1] https://github.com/mickeynp/combobulate
[2] https://github.com/nvim-treesitter/nvim-treesitter/wiki/Extr...
[3] https://docs.helix-editor.com/usage.html#navigating-using-tr...
[4] https://github.com/bablr-lang/
It makes sense to benefit from this sort of thinking in other languages, but this is just another reminder, to me, of the beauty of lisps.
A fun language idea would be to take the exact semantics of an existing language, like C++, and encode them within a lisp, losslessly. I suspect it would end up quite verbose. However, add in a macro system and then you can start building a DSL around the original language, keeping all the same underlying semantics.
The difference here is that the lisp's AST would need to map 1:1 with its underlying language.
https://www.youtube.com/watch?v=D6h5dFyyUX0&t=51s
https://paredit.org/
https://www.emacswiki.org/emacs/ParEdit
The one thing I don’t like is that symex depends on so many other plugins (especially Evil, which I am trying to swap out with the more lightweight meow), but this will apparently change soon. They are also working towards support for non-Lisp languages via tree-sitter, but I don’t know how well it works.
[1]: https://github.com/drym-org/symex.el
Consider, most of us work in rather phonetic languages as we type day to day. Surely it would be easier if we worked instead in languages where you did not have to do this. Let me type only valid sentences as I move from thought to thought. Surely that would be better? Why, then, do we not do that?
Of course, I don't know why. I suspect there is a good deal to inertia style thoughts that explains this. But it is a good hint that the idea that you can break apart from symbols that need more symbols for context to build meaning is not one that really anything has fully converged to.
For example if I decompose the sentence "I press play" into words devoid of context, "I" still pretty much means what it did but "press" could now as easily mean pressing shirts or pressing an advantage, and "play" could be what children do, not the implied "play button".
A good semantic editor for that sentence would allow me to detach the word "play" without losing the context that the meaning is "play button". Similarly a good semantic code editor would let me do something like pull two non-adjacent class methods out of a class and into a clipboard, then drop them into another class. If you did this this with text, the editor would not understand the clipboard content as class methods are (usually) not parseable outside a class.
You can argue that I should be able to copy a method invocation and move it, but I confess I don't even really understand what that would mean or how it would help me. More, you are fixed in a global evaluation sense of the work, now. What if I want to take a formula in code, evaluate its derivative, and then use that for evaluating input? (That is, the exact same code depends on where it is
But, again, my point was not that we can find the reason it doesn't work. I don't know the reason it doesn't work. I don't even know for sure that it can't work. What I do know is that no other communication has distilled to this level of editing. Happy to be proven wrong.
I had meant to edit my post to refer to this all as "a" problem that this idea will face. Specifically that no other editing of anything that I am aware of happens at this level. There are some neat composition tools that can put together some scenes in this way, I think. Such that maybe there is more of a generalization there than I think there is. Seems very unlikely, though.
Now, oddly, I do think software is best made to enable this style of construction for what it controls. Easy example would be a level editor in a video game. That makes surprisingly little sense to do in a symbol based editor, as opposed to a palette based visual editor. Such that I think I'm open to the idea, at some level. Symbol manipulation is just not that level, for most things.
Oddly, I do think there is something to making sure all of your data has a literal representation in the code, if you can. Such that I do think being able to directly interact with data is huge. I also love when you can symbolically work with programs.
But, yeah, the overwhelming evidence is that this just isn't necessary for things. Both in communication, and in program specification.
gif shows the user editing text
One interesting thing about GPT&cetera is that in order to "cheat" by using it, you need to clearly describe the problem you are trying to solve. If we can get more people to design before coding begins, I think we're going to have a win in any case.
I’m building a semi-structured editor for UI - I’ve described it as “vim for designers.” Just as an example of how varied the general idea can be.
1. Bias. A lot of people think that if good ones haven't been built already, there must be some reason they can't be built
2. You really want the parser to report not just what types of nodes it found at particular locations, but what types of nodes it could have found at that location, because those are the types that will be valid for insertion there. A semantic editor needs to know because it should only be able to create programs that the parser would be able to parse.
3. Extensible parsers: To make a huge number of parsers that exactly match languages, you need to be able to quickly define parsers that are closely related to each other, and what's more the cost of using the derived parser must be closely related to the cost of using the original. Tree-sitter can derive languages at compile-time, but not at runtime leading to three major problems:
- 3.1 Runaway storage costs: the Tree-sitter grammar for JS is ~4mb, and the grammar for TS is ~12 MB and the grammar for TSX is also ~12mb and these grammars have things they shouldn't have in them like Ember's glimmer syntax, because that syntax is too poorly supported to justify paying the costs of copying the JS, TS, and TSX grammars (causing 28MB of new code duplication, in git no less).
- 3.2 Failed semantics: Because the JS runtime grammar is just code copied into the TS runtime grammar, tree-sitter can't distinguish which parts of TS programs are really just plain JS.
- 3.3 Umbrella languages: Because the grammar defines languages that are bigger than what you can actually use, the JS tree-sitter grammar will happily parse JSX even when it's invalid, which is to say a semantic editor would suggest inserting JSX even when it would break your program, which is clearly bad.