Hi Abraham,
A thoughtful question, thank you!
An pure functional approach is documented here, in particular section
3.3 but take a look at least 3.2 first:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.1406&rep=rep1&type=pdf
In brief it describes a plugin system for the Yi text editor, which
treats persistent state across code hot-swaps as a kind of
serialisation problem, where state requires translation if its type
changes in the interim, or defaulting if it the state appears from
nowhere.
I'd say it's a hybrid of 3) and 4). Because this is pure functional
programming, all state is carefully managed, and so there is no need
for dependency analysis or code transformation. It might be surprising
that a strongly typed, pure functional programming actually makes live
coding with state *easier* (if you squint hard enough, at least).
Note that Yi will have changed a lot since this 2005 paper, so is
probably doing things differently these days.
In feedback.pl I kept state in two places:
1) in an associative array which was just kept between
re-interpretations of the Perl code
2) in the sourcecode itself, generally in comments but also by
updating assignment statements.
The latter worked out really well, because the state would of course
be saved with the sourcecode, and also the programmer could see the
current state of the variables, and do simple text-based
visualisations of the program's operation in the source.
Feedback.pl also did sandboxing similar to Davide's description of
livecodelab, so that compile-time errors didn't result in silence. I
didn't do his cunning runtime quarantining though..
In my current 'tidal' Haskell EDSL I don't really have any state apart
from time, so I avoid this problem. :)
alex
On 3 August 2013 12:32, Abraham Coetzee <abraham_at_ml.sun.ac.za> wrote:
> 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
--
http://yaxu.org/
Received on Wed Aug 14 2013 - 19:48:06 BST