Projectional / structural web editors with Elm - Progress video

Hi all,

I created a video showing some progress on an API I’m working on to build your own projectional / structural editors with Elm. This is experimental at best. Yet, I was wondering if some of you might be willing to look at the project and provide feedback.
The video first shows an example editor for a simple state machine language, before looking at the code to build it.

Notice that I haven’t found the time to add a README or anything like that to the repository. If I decide to follow up on this project more seriously, I will certainly do that.

I appreciate any feedback.


Nice work. I think this is really neat. It looks easy to use and I could follow along without any issues.

Also, I’m interested to experiment with this idea myself. I have been looking for a way to do something similar but includes models with a lot of text as well as relationships. The use case I am thinking of is more modelling business needs and requirements for engineering etc.

1 Like

Thank you for your feedback!

I have identified some issues I’m currently struggeling with, mainly with introducing strong node IDs. I’ve read a bit about other approaches, from elm-UI to elm-css and working with generated UUID, for example here: Enforcing unique ID

I haven’t had time to really think all the alternatives through, but I haven’t really found a way I like in order to have strong IDs and thus features like “node references”.

Another issue I have is that, in my approach, the central type is a Node a, so that each node in a tree must feature the same data type. This makes it impossible to mix languages, as far as I can imagine it. One way I tried was to just get rid of the unbound type a, and say everything is just a Node, but this loses even more type safety in Elm, since I would have to work with strings or something similar primitive to “tag” nodes and distinguish them at runtime. I currently opt for keeping the “typed nodes”, losing the ability to mix trees.

I’ve a modelling background, so if you want to you could point me to some model examples or describe your modeling use case here and I can try and see if I could map it to my current prototype somehow. The “challenge” with modeling with text is that text is unstructured by itself, so one needs to have some sort of parsing in place, which is exactly what the idea of a structured editor avoids.
I’m currently also started to look into tree-sitter a bit to see if I could laverage it to nicely play with strucutral editing. Cause with incremental parsing and a concrete syntax tree that is “always live”, text editing all of the sudden becomes very similar to structural editing.

I created another video, showing some new features and a bit of hands-on development, extending the graphical projection of the demo statemachine:

It’s easy to get lost in playing around with SVG rendering and related features, so what would really help me is if this community could suggest some other languages I could try to build with what I currently have. I plan on adding a basic tabular projection next, but if some of you have ideas for other languages I could try to build first, please let me know, cause I think deriving features from specific use cases is a reasonable approach given the current state I’m in.


1 Like

Great work. Made my curiosity hormone spike :smile:

I’m thinking you could keep the type variable in the Node a. If someone wants to mix two languages, they could use a Wrapper type that contains tagged values like WrapperA LanguageA and WrapperB LanguageB. A small supporting cast of mapping functions could handle the redirection of each language node to their own API’s.

I’m in the thinking phases of a domain specific app that would greatly benefit from a library like this. Please keep up the good work :grin:

1 Like

Thanks, I haven’t even thought about that, but it seems like an obvious option. Will look into how this could be supported.

Seems like not long ago you were here asking whether writing something like this in Elm would work, and now you have something that looks really interesting - very impressive.

I am curious about something… How do you find the experience of editing the ‘code’ on the left hand panel, compared with editing normal code in a text editor? Can you do everything without taking hands off keyboard and using the mouse? Can you do all navigation around the ‘code’ just using keyboard arrow keys, pg up, pg down, tab, etc?

The reason I ask, is that I have a hypothesis that the reason programmers still use text editors and that more graphical systems have never caught on in a big way, may be down to keeping the editing experience relatively mouse free. I always preferred things like Emacs over the sort of Windows GUI editors that we use to have to put up with (not really used it much, but I believe VSCode has come a long way). That hypothesis is not the whole story - text also seems like a compact way of describing code that is well optimized for describing the kinds of things that code needs to describe.

I also never really grokked Jetbrains MPS, so never got as far as understanding what it is really like to work with. But it is fascinating to see what you have done here, and curious to see how you think it plays to the strengths of text editing versus graphical manipulation.

Hi Rupert,

this is a very interesting point. This reply might go off topic, so if this is a problem somebody just let me know.

I’ve been working in language engineering for many years, both in research and in different industries, and it is a reoccuring question: textual vs. structural editing, what’s better?
As you might imagine, there is no wrong or right answer to that, in general. Both approaches have advantages and disadvantages, which is why I find the tree-sitter project so exciting. In this presentation, you can see how they are able to perform high-level operations on a text file, which are usually things you do in structural editors (starting around this time code).
When you interact directly on a tree (like the AST of a program), you can start manipulating a program more in terms of “expressing intentions”. Think of those like (fine-grained) refactorings. “Move this statement up/down”; “Extract that into a variable”; “duplicate this expression three times”; “substitute this expression with that expression”.
Such refactorings are available in many IDEs as well, but they become more second nature when you operate on the tree directly, I think.

I could list many reasons why I think structural editing should be superior to text, e.g. it allows you to not only represent information as a sequential stream of characters, but arbitrarily. The most famous presentation on that topic (in case you don’t know it, please watch it, I think it is a must-see), is Bret Victor’s Future of Programming. Despite all the points he makes there, we (programmers) still like our little text editors. And you are rightly pointing out some nice features of text, like its compact way of decribing code.

But to answer your question more specifically: yes, you can certainly work a structural editor without ever reaching for the mouse (even true for my prototype, although the selection still goes haywire often enough, but you can recover with the tyb key very reliably).
In many cases, especially if the structural editor looks a lot like a textual representation would look like, this makes a lot of sense. When you have a state machine as a diagram, like in my example, you want to use the mouse to move the nodes at some point.

Where the structural approach can really shine is for DSLs. I’ve been involved with a project at Siemens Healthineers, where we used MPS to build DSLs for physicists to formally descibe the runtime protocols of CT scanners. The data needed to be presented in a tabular notation, it was just the most natural way to yield it, yet the users also profited heavily from features we know and love from programming, like having type safety, static evaluation, scoping, model execution (aka running a program), etc. The lines between “code” and “models” are blurry, and I usually don’t distinguish between them. What does make sense, though, is to distinguish between user groups (programmers / non-programmers, for example) as well as use cases (manipulating data / reviewing data).

To emphasize this second distinction, take a look at the following screenshot. It shows the default editor for something very “Java-like” on the left in JetBrains MPS’s default editor, and the same code in a editor I’ve prototyped once for the main purpose of code reviews. It’s not perfect, but I guess you get the idea why the right side might be better to comprehend and discuss code in a review.

So I guess my bottom line is: yes, text is really the prefered way for the target group “programmers” and the use case “editing code”. For many other target groups and use cases, it might be very beneficial to have other editors/views.

Thanks for your extended thoughts, I found that fascinating. Can also see why you might want to try this stuff in combination with Elm - I am now imagining the next generation of CT scanners, physician opens the electron-based config app, nice slick UI in Elm, and builds up the scan program to suit the patient.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.