I'm looking for papers / projects / programming languages in which the presentation / editing representation is text and the storage representation is decoupled from presentation / editing. In typical programming languages these representations are the same (code is edited as text and stored 1:1). In structured / projectional editing environments the editing representation is often non-textual. Even though these environments separate presentation from storage, it seems like a by-product while the focus lies on the editing experience. I'd like to see studies of the implications of separating presentation and storage representations for programming languages. I can imagine that this could help backwards-compatible language evolution, end a lot of syntax bike-shedding discussions and probably even let different programming languages share common concepts. I'm not the first one to think about this for sure, but I didn't manage to find useful resources.

You might look at the Intentional Programming project. https://en.wikipedia.org/wiki/Intentional_programming

@Felix Kohlgrüber I hope you're doing well! At Storyscript we have a projectional editor which doesn't show syntax errors per se, it only says when code is correct and "runnable". We couple that with "grammar suggestions" like in MS Word / Grammarly to help show you how to make corrections. In this way, any syntax that isn't "valid" is simply stored as stylable text. It took a lot of trial-and-error to figure out how strict our exportable/saveable representation would be to an AST, but we struck a pretty good balance IMO (leaning more towards flexibility / error tolerant than what we started with). A part of our approach was made more complex, because we threw the whole "compilation pipeline concept" out the window, and went with managing our authoring tool using an ECS data model (like in game development)

@Doug Moen Thanks for bringing Intentional Programming up. I heard of it but never really took a deeper look. It's time for that I guess. Regarding mapping into the storage representation: I would be ok with not allowing to save code that contains syntax errors. It shouldn't be too hard to bring code into a form that parses, and on the other hand this forces you to deal with these kinds of errors early. Committed code and input to compilers would be guaranteed to be well formed to some extend, which I think is a good thing. Structured editing doesn't work IMO when requiring each edit to map from one valid AST to another valid one. There's just to many operations needed for this to be practical. Text editing allows composing a few simple edit operations into larger transformations, kinda unix-philosophy style.

Hey @Cole, I'd be interested in knowing more about this. Especially the 'throw away compilation pipeline model' for ECS. I'm a game developer :)

@Felix Kohlgrüber You might want to check out Ryan Fleury's work-in-progress "DION": https://twitter.com/kevinwatters/status/1261371419201548289

@Cole Sounds interesting! I've tried building really strict program representations before (e.g. ones that can't represent programs with unresolved names) but it turned out to be a huge pain. I'm currently leaning more towards simplicity and flexibility which matches what you've experienced.

@Felix Kohlgrüber I know that Ryan has explained it a bit on HMN - the basics are that each node in the abstract syntax tree is kept at a fixed virtual address in memory, so can always be uniquely and stably referenced. When saving to disk, I think the total virtual address space is broken up into "megachunks", such that libraries that would otherwise have conflicting virtual addresses can safely interact. I don't know much more detail than that. I'm aware he recently rewrote a fair amount of code and I'm not sure exactly what has changed. I suggested he join this community, but he's pretty busy, so not sure if he will. He regularly answers related questions on the HMN discord if you want to probe further: https://discord.gg/hxWxDee