Timers or UI actions seed this scheduler, otherwise nothing happens. And nothing interrupts an execution chain until it’s stack is done.

Because I see Reinteract as a tool for creating records of computational experiments, I’m not necessarily so interested in going completely dynamic … you move a slider, the playing sound changes. It’s related, but a different emphasis. That also reduces the interest in multithreading and parallelism… to me the main reason for adding threading would simply be to not block the users during a long-running computation.

I should point out that there is no real data-flow analysis going on in Reinteract currently. Each statement is considered to depend on all the statements above it. Better dependency analysis could be done and probably eventually will be done, but I haven’t found a huge need for it yet.

Many data flow languages are visual and include pd (pure-data) and Max/MSP. They all have this always-on-ness that is presented here.

The always-on-ness makes a language very useful for gestural programming. By this i mean, that one can change them and see/feel/hear the result immediately. Something of the feedback and artist uses in see their hand gesture on the canvas. This is exceptionally important for programming as composition, for example in generative sound composition.

Once again brilliant.

Another advantage of visual data flow languages is that they have many tops (main loops if you want to thing of it like that)

This means that creating parallel action/processing is very easy. This is also very import in creating a multi-layered work.

Can reinterpret have multiple instances that live in the same sand box?