| ▲ | jasonjmcghee 6 hours ago |
| I've dabbled a lot in this space as well- built an experimental language that natively supported live-coding, after building live coding capabilities through LSP for love2d (Lua) to get a feel for the feature set I wanted etc Love2D Demo https://github.com/jasonjmcghee/livelove Language Demo
https://gist.github.com/jasonjmcghee/09b274bf2211845c551d435... |
|
| ▲ | tov_objorkin 6 hours ago | parent [-] |
| Nice, the main problem is a broken state. I use immutability at the language level to prevent disaster code changes. So, the program during live coding is literally unkillable, and you can jump back to the saved checkpoints without restarts. |
| |
| ▲ | jasonjmcghee 6 hours ago | parent [-] | | Yeah the language here has a notion of the "last good state" so it can keep running. In the demo I'm not hitting "save" - the moment there's a good state, it becomes the "current version" - but there's no reason it needs to be that way. I made the decision that state management is manual - the "once" keyword. Any expression/block not using "once" is re-evaluated any time there's a change to the code. If it's using it, it only re-evaluates if you change the (depth 0) code of that once wrapped expression. | | |
| ▲ | tov_objorkin 6 hours ago | parent [-] | | In my case, only part of the program is recompiled and re-evaluated. The rest is located in a "committed" frozen area. Users can try new changes and throw them freely. The editor performs an evaluation/rollback on every keystroke, ensuring no accumulated or unintended changes to the stated were made during editing. When the user is satisfied and hit run, a long-term snapshot is created and the source code snippet is moving to the frozen area. Thats critical because the edit also rollback the file positions and streams. |
|
|
