Source code information

[wolfadex]

As I think about the ambitions for the editor, and trying to think of what can be done with the idea of

ambitiously boundary-pushing graphical editor

I've wondered what that means for the source file. As an example, traditional source code is treated first and foremost as plain text and then the editor is responsible for parsing through that plain text and creating meaning. Is there anything we can learn or borrow from non-plain text tooling, such as MS Word or Google Docs? An example from those being their comments exist parallel to the readable text, and are accessible as a panel displayed to the side of the readable text. What changes are required to be made to the source file in order to achieve this? Is this desirable? What are the costs?

Not sure this is worth it, but I figured it's worth thinking about considering the ambition.

[rtfeldman]

I've definitely given this some thought!

I generally start from the position of "Suppose we didn't have to have textual source files. What benefits could that unlock?"

Some things come to mind:

1. Recording transformations to improve automatic merge conflict resolutions. For example, if I do a "rename" operation on a function name, and I'm collaborating with several other people, the semantic information about that transformation could let tools resolve apparent conflicts between what I'm working on and what others are working on. This is even more true when doing more invasive changes than renames, e.g. deleting an argument (including from all of its call sites).
2. Storing things in a more efficient format than plaintext.
3. Including extra information besides definitions and documentation - for example, editor plugins, or repl/"playground" sessions where people were poking around trying things, and wanted to persist those sessions so they could be shared with others.

I don't think it's right to seriously consider alternatives to traditional textual source files until significantly later than the language's initial public release. Some reasons:

1. A language can only spend so many "strangeness points" before it becomes too risky for a lot of people to consider trying. Being a pure functional language with polymorphic variants instead of subtyping is already a lot of strangeness points, and the whole editor concept itself is even more! I don't think "non-textual source code" is worth the strangeness points for Roc. (Unison spends a lot of points on this, but for Unison it's a foundational part of the language!)
2. If it's not going to usefully work with traditional version control systems, then we'd also need to invent a version control system to go with it. (Maybe that'll seem worth it someday, but it definitely doesn't at the moment!) Alternatively, we'd need to figure out how to integrate it smoothly with existing version control systems, which could also be a big project.

It's possible to consider a "middle ground" approach where we have a traditional textual source file format, but with additional annotations that aren't intended for human consumption.

There's already a precedent for that in documentation comments, and we could potentially take it further...but I'd want to be careful not to overdo it and risk ending up with a "worst of both worlds" scenario, where they're textual source files but they're so bloated with annotations and metadata, they no longer work very well with existing version control tooling. 😄

[Anton-4]

I could see recording transformations/edits being very valuable for a smart code assistant. I think it's very difficult for current machine learning models to create a working block of code in one go. It seems a lot more tractable to perform a chain of edits.

The model could learn how to fix common errors based on shared patterns in the recorded edits of github repos that previously encountered those errors. Definitely future stuff but interesting to think about :slightly_smiling_face:.