I super enjoyed the last installation of this. I think I've watched every talk twice. I'd love a similar format for a selection of language design talks.

I'd love to try implementing this in some other languages.

Indeed. Here's a link to one episode https://pod.link/developer-voices/episode/e47720e8c6dc3d1660...

What requires the format to be text-like? I'm not sure I agree with this assertion. I think structural editors need to be language specific so that they can offer higher value edits that might only make sense for specific languages.

"Text-like" meaning easy to parse and universally understood. With language-specific (or indeed, all) AST/generic tree attributes serialized in a uniform way that does not entirely break parsing if an editor does not understand one of them. I.e. I can edit code even if my editor doesn't understand the language and doesn't give me syntax highlighting and completion. More, that that 'understanding' can be factored out of the editor core, as is done with language servers today.

The EYG type system does support recovery, so you will get multiple type errors if that's the case in the program.

My point is that type error recovery is the property of the type system. Not the property of structural code editor.

It could be in principle. EYG was developed along with the editor so that has effected the design of the AST. Ideally if a useful/powerful/pleasant/intuitive structured editing experience was found for EYG (and it's minimal AST) then it would be proven to work and so putting the effort into doing for a program with a more complex AST would be worth the effort.

I'd really like to get to the point where I have a library of transformations and you can make your own interface. Already the click ui and hot keys ui call the same `insert_function` or `assign_to` functions. Adding a ui with lots of dragging or voice control should be trivial

I’ve actually moved away from GUI controls and towards something resembling a keyboard command language. Similar in spirit to vim motions, but instead of applied to text, it’s applied to an AST.

I think that could be the key to making structured editing feel less “clunky”.

That's interesting! Do you have any of it in a public repo?

I have an older repo that briefly describes it at a high level: https://github.com/matry/editor

I've moved on to another (private) repo, but it should be shareable soon.

That's a cool idea. I think the arrow directions you chose for sibling and parent/child directions are very intuitive.

Diffing is really an interesting point. Git is quite (maybe very) good. I wonder how much better a structured approach could be but it's obviously a large amount of work that I don't yet have time for.

Plain Text diffing has some obvious drawbacks:

1. If you rearrange your functions you will see a lot of additions and deletions while semantically there is no change in the program. It's just noise.

2. If you rename a variable you don't really have any actual change in places where it is referenced but text diff will again show a lot of noise. But the code references is still the same code.

At least to me whitespace does convey meaning and order of functions or variable renaming definitely conveys a semantic change.

> variable renaming definitely conveys a semantic change

I didn't say it doesn't. Renaming is a change and you see it but you don't need to see it in every place that refers to that variable. For them there is simply no semantic change they still reference the same variable.

> At least to me whitespace does convey meaning

Can you give an example? If two programs behave exactly the same how whitespace convey a semantic change?

> order of functions

You can see order changes in a structured diff as well if you want but you don't need to hundreds of line of removal and addition like text diff. You would see only the relevant thing which is reordering.

> Can you give an example?

In C, I use FOO() for a macro, foo() for a function like macro and foo () for a function.

Also:

  statement1;
  statement2;

  statement3;
  statement4;

is different from:

  statement1;

  statement2;
  statement3;

  statement4;

Can you still see those changes in a structured diff?

> You can see order changes in a structured diff as well if you want but you don't need to hundreds of line of removal and addition like text diff. You would see only the relevant thing which is reordering.

That is nice then, I thought diffing an AST would lose that ability.

Modern SmallTalks have the option to save off a hierarchy of classes to text in order to use modern version control, and also to apply these exports to a running image. This should be even easier for traditional languages with no live running environment. There's no reason whatever structure editor you use can't export a normalized text representation so that you can still use it with Git

> the option to save off a hierarchy of classes to text

And so did ancient Smalltalks.

1984 "Smalltalk-80 The Interactive Programming Environment" page 46

"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."

https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...

I did not realize this! Thanks for sharing.

Git (or whatever does the diff under the hood) is _adequate_. Every week I see diffs that are confusing, especially during merge conflicts, it’s honestly a bit embarrassing that in this day and age we don’t have anything better for something that is so central to our job

A structured approach would be able to easily do things like ignore when a symbol was renamed (since that wouldn't affect the tree structure). So there are good reasons for wanting to do it that way, vs. a line-based diff.

I'd love to get this to the point where add your own keybindings to structural edits, potentially very involved ones. It's superficially not very different to a combination of vim macros, auto completes or templates in other editors but I think the end result could be interesting as the units of change would be more meaningful. I think it's the same benefit of a hygienic macro system vs a source file manipulating version of meta programming.

The code editor is for the EYG language and implemented in Gleam. So that's a blocker. The editor is probably far enough along to have a crack at it by EYG would need some UI or web library so that EYG was able to build an editor.