On Sat, 2007-03-24 at 22:17 +0100, Julian Rohrhuber wrote:
> I agree entirely. While as far as I know, that
> "For example, editing the imperative Smalltalk
> statement "w fill:red" to "w fill: blue" will not
> immediately re-color blue all widgets that have
> been bound to w." is presented as a prototypical
> example for the need of re-evaluation is
> misleading - but even more, it is based on an
> overly simplistic notion of presence. There are
> also some overly simplified ideas about what
> "immediate change". The interesting thing about
> interactive programming is the temporal
> multiplicity it causes.
I've been trying to digest this paper more thoroughly, it's difficult
without using the language itself and not having clear grasp of all the
terms or the other languages mentioned. But I think there is something
in the "w fill:red" to "w fill: blue" will not immediately re-color blue
all widgets that have been bound to w."
Imperative programs tend to have a lot of initialisation, and I have
found it difficult to know what to do about that when live programming.
Also, what do you do about sub routines that don't return -- how can
they be replaced? Worrying about this kind of thing puts a lot of load
on the live programmer, who has to construct their program in a certain
way.
Having a chain of functions connected together, and some way of
replacing one function with a new version, with a continuous stream of
data flowing through the functions with lazy execution seems a nice
solution, and AFAICT is how diagrammatic programming languages like PD
works. I think this is what this paper is proposing for textual
languages. I suspect an elegant way of doing this in a pure functional
language is possible with a clever monad.
alex
Received on Sun Apr 01 2007 - 12:10:25 BST