Hi Abraham, I can talk about how I'm approaching this with my hobby project
Circa..
Circa mainly follows approach #3. There is a language keyword "state" which
declares that a value is part of the program's persisted state. So, the
runtime is able to extract the persisted state from a running program, and
it can attempt to load that state into a slightly different program. I
wrote about the approach here:
https://github.com/paulhodge/circa/blob/gh-pages/about/inlined_state.md
On the subject of #4, there is definitely an interesting philosophical
issue there. Whether to a) migrate the current state into the new code
(even if it doesn't quite fit exactly), or whether b) to replay the program
as if the new code is what existed the whole time. In Circa, values marked
"state" always follow approach (a).
I've talked to some folks who say that (b) is the only way to go, but I
find that there are a lot of pragmatic benefits to (a). The example that
I've started tossing around, is say that I'm implementing a text editor. I
start writing a document in the editor (so my text document is the state).
Then I decide to add VI style keybindings to the editor. It would be pretty
surprising if my existing text was reinterpreted as a long series of VI
shortcuts.
Anyway, my secondary approach to #4 is to try to avoid introducing
persisted state in the first place. These days I'm working on adding a
builtin memoize system to Circa. A function like "load_image" can be
annotated to say "memoize this", so that the 2nd and subsequent calls to
the function will reuse the previous result (if called with equal inputs).
The user can add these expensive calls into the program's main loop - they
aren't separated into a different "load" or "initialize" step - and it all
works efficiently. If there is a code change inside a memoized function,
the old results are thrown out and it is reevaluated. (But if a memoized
function was not changed then old values can be preserved). So, memoized
functions should always return the same result as if the program was
started from scratch. I think this works as an okay solution to #4.
(I guess you could argue that a memoized result is a form of state, so I
might be playing with semantics by saying that memoizing is different than
state, apologies).
Best of luck, it's an interesting topic!
Andy
On Sat, Aug 3, 2013 at 4:32 AM, 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 Wed Aug 07 2013 - 16:19:57 BST