Hi Abraham,
A note on you point 4 (which is the one of the subject): I toyed with that idea but in general it looked very difficult. Static analysis (by that I mean "compile-time") of "loose" and "general" code is very difficult, for example it's impossible to statically detect all the unreachable code (detecting some cases of unreachable code is "easy", but in general it's impossible), as it is to tell any non-trivial property of a program that has not been precisely engineered to be statically checked (e.g. type systems). We thought of solving that by enforcing enough structure in the code, but then we ended up with cumbersome syntax, it looked to me like this wasn't the right way to go...
I can't speak of the general taxonomy of the runtimes of livecoding systems (sounds like a topic for a paper), but I can tell the thinking behind livecodelab
https://github.com/davidedc/livecodelab , where the program is run as the user types.
There is no CTRL-enter or shift-enter, no "play button" - the program just runs while typed. If you want to suspend the evaluation of the program temporarily, just add a simple syntax error (like a slash somewhere it shouldn't be, or an unbalanced parenthesis), and then remove that syntax error when happy.
We could have made use of an explicit play/pause button, but we are trying to see whether we can dispense of that "modality".
So, at any moment, the typed program can be syntactically correct, or not. If it's syntactically correct, then it's run 60 times per second. So the effect is that the animations keep going while the user types (and while typing, inevitably some transient syntax errors happen).
Now - that covers only the "static" check (typos, syntax errors) that happens immediately while the user types.
The second check is at runtime: for example one might exceed an array boundary - i.e. that sort of errors that one can only detect at runtime.
To address that: the program, if syntactically valid, is kept in a "quarantine" state for a few seconds. If the program runs without runtime errors for the quarantine period, then we are going to judge it as stable and save it in a "stable programs" history. If the program fails at runtime at any time, then the previous stable program in the history is run (that might fail as well at some point, so we fallback to the previous, etc.).
So that's how the animations keep going and updating while the user types the program, and how we hopefully avoid stopping at runtime errors.
Second question is: what to do with state accross calls of the program? Where to initialise it if the program is continuously run? There is some work in progress there (state is not fleshed out yet), but the skeleton is the following: you can initialise state in special "doOnce" blocks like so:
âś“doOnce:
this block runs ONCE when the checkmark is deleted
The key thing here is that checkmark: if you delete that checkmark, then the doOnce function is run, once, after which the editor puts that checkmark back in place again.
Note that you can have as many doOnce blocks in your code as you want. It just so happens that if you want to initialise global state, then you want to have one doOnce block at the beginning of your code. At any point, you can use a special function to clean the whole state.
When you save your code, the checkmarks are not saved, so when the program is loaded all the initialisations happen.
The doOnce mechanism is in place, but the state accross calls of the program is not fully fleshed out yet - mostly because we can do awesome stuff without it - we need very little state to do amazing animations, and we can build simple state really quickly based on the frame number or the time.
Cheers,
Davide
On 3 Aug 2013, at 12:32, Abraham Coetzee <abraham_at_ml.sun.ac.za> wrote:
> Hi everyone.
> I'm a computer science masters student at Stellenbosch University, South Africa, and am investigating live programming as part of visual thinking in computer programming.
>
> I am curious about the different ways employed to propagate source code changes, in running as well as 'paused' programs (say at a breakpoint). It would be very interesting to know which live programming/coding systems use which approach, so that one can take a look at other, similar systems when developing one, or design systems which are unlike any before. I am interested not as much in 'transient'/ephemeral code, but more in 'permanent' code where the program is always linked to- and (the algorithm) reproducible by- the final source code. Perhaps one could also say, not transient code where the state/outcome produced that single time is the most important (often the case when using a REPL setup), but I am thinking more of permanent code where the final, created code is important (often the case when using an edit-compile-run-debug cycle). Though of course both transient and permanent programming have their place.
> For instance:
> 1. When code is changed, the program might end and then simply re-execute from the start.
> 2. A library, when changed, could just be reloaded so that the next time it is refered to, it produces different results. (Though I think this isn't quite 'permanent' as the program partly executed using older code and so the current state might depend on what the code use to be.)
> 3. The programming language or system is designed so that state is an entity that can be worked with - e.g. saved and again loaded when the program is re-executed with new source code.
> 4. Some sort of dependency analysis to figure out what consequent code is affected by a code change. Then either where in the source code to back up to and re-execute from, or how to transform the current program so that it is as if it executed with the new source code in the first place.
> - Any others? Those are all I can think of.
>
> I'd appreciate your input.
> Thank you,
> Abraham
Received on Mon Aug 05 2013 - 11:05:12 BST