>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."
of course, but it is only the tip of the iceberg.
>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.
In SuperCollider, both patterns and UGens are purely functional
higher order constructions. The whole purpose of JITLib is to allow
to impose changes on those structures that map in a meaningful way to
their extension (calculation process or sound, dependent on the
perspective). Depending on the underlying model, this mapping may
vary, but the assumption of "immediacy" is not valid when the model
of time is an abstract / structural one. Pattern proxies generate
coroutines that can be modified even if they do not return. Node
proxies abstract from buses and allow to refactor synthesis graphs on
the fly, so that parts of them can be exchanged. All proxies abstract
from evaluation order as far as possible, and provide meaningful
"empty" values. For me, the problem you describe has been the source
of the idea of live coding in a way.
--
.
Received on Sun Apr 01 2007 - 13:11:11 BST