mirror of
https://github.com/roc-lang/roc.git
synced 2024-11-11 16:51:53 +03:00
6.5 KiB
6.5 KiB
(For background, this talk has an overview of the design goals for the editor.)
Editor Ideas
Here are some ideas and interesting resources for the editor. Feel free to make a PR to add more!
Sources of Potential Inspiration
These are potentially inspirational resources for the editor's design.
Package-specific editor integrations
(Or possibly module-specific integrations, type-specific integrations, etc.)
- What FP can learn from Smalltalk by Aditya Siram
- Moldable development by Tudor Gîrba
- Unity game engine
- Scripts can expose values as text inputs, sliders, checkboxes, etc or even generate custom graphical inputs
- Drag-n-drop game objects and component into script interfaces
- How to Visualize Data Structures in VS Code
Live Interactivity
- Up and Down the Ladder of Abstraction by Bret Victor
- 7 Bret Victor talks
- Against the Current by Chris Granger
- Sketch-n-Sketch: Interactive SVG Programming with Direct Manipulation by Ravi Chugh
- Xi modern text editor with concurrent editing (related to Druid)
- Self programming language
- Primitive code exploration in Virtual Reality
Debugging
Structured Editing
-
Deuce (videos on the right) by Ravi Chugh and others
-
Fructure: A Structured Editing Engine in Racket by Andrew Blinn
-
- code editor as prose writer
- live preview
- possible inspiration for live interactivity as well
-
- Blueprints visual scripting (not suggesting visual scripting for Roc)
-
Live Programing by [Microsoft Research] it contains many interesting research papers.
Non-Code Related Inspiration
- Scrivner writing app for novelists, screenwriters, and more
- Word processors (Word, Google Docs, etc)
- Comments that are parallel to the text of the document.
- Comments can act as discussions and not just statements.
- Easy tooling around adding tables and other stylised text
- Excel and Google Sheets
- Not sure, maybe something they do well that we (code editors) could learn from
Machine Learning Ideas
- Ability to record all changes to abstract syntax tree with user permission.
- I think it is possible to create powerful automatic error resolution by having a dataset available of ast's with a specific error and the subsequent transformation that fixed the error.
- GPT-3 can generate correct python functions based on a comment describing the functionality, video here. It's possible that training a model using ast's may lead to better results than text based models.
- Users with large private code bases could (re)train a publicly available error recovery model to experience benefits without having to share their code.
- It could be useful to a user who is creating a function to show them the most similar function (type signature, name, comment) in a public+their private database. Say I was using a web framework and I just created a function that has a multipart form as argument, it would be great to have an example instantly available.
General Thoughts/Ideas
Thoughts and ideas possibly taken from above inspirations or separate.
- ACCESSIBILITY!!!
- From Google Docs' comments, adding tests in a similar manner, where they exists in the same "document" but parallel to the code being written
- Makes sense for unit tests, keeps the test close to the source
- Doesn't necessarily make sense for integration or e2e testing
- Maybe easier to manually trigger a test related to exactly what code you're writing
- Ability to generate unit tests for a selected function in context menu
- A table should appear to enter input and expected output pairs quickly
- Ability to show import connection within project visually
- This could be done by drawing connections between files or functions in the tree view. This would make it easier for people to get their bearings in new big projects.
- Connections could also be drawn between functions that call each other in the tree view. The connections could be animated to show the execution flow of the program.
- Ability to inline statements contained in called functions into the callee function for debugging.
- The value of expressions can be shown at the end of the line like in the Inventing on Principle talk
- This would give a clear overview of the execution and should make it easy to pinpoint the line where the bug originates.
- That specific line can then be right clicked to go to the actual function.
- Having to jump around between different functions and files is unnecessary and makes it difficult to see the forest through the trees.
- "Error mode" where the editor jumps you to the next error
- Similar in theory to diff tools that jump you to the next merge conflict
- dependency recommendation