Maybe related, there is a lot of discussion recently in "reactive" javascript frameworks, a famous one being "Elm", see this recent article which basically shows a livecoding environment, with a discussion of how state/API continuity is handled.
http://elm-lang.org/blog/Interactive-Programming.elm
(Elm needs a server to do the compilation, which is kind of a bummer, but other libraries such as bacon.js are entirely client-side. If someone is up to experimenting with those give me a shout :-)
Cheers,
Davide
On 14 Aug 2013, at 20:47, alex <alex_at_slab.org> wrote:
> 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 Tue Sep 03 2013 - 15:13:16 BST