Oops. I should have used "reply to all".<div><br></div><div>Let me try again and be more complete this time;<br><br></div><div><br></div><div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

It's a problem with waiting for stuff to happen, I think. To multiplex separate<br>
logically continuous, but not temporally coherent streams of steps, you<br>
typically have to ride a monocycle juggling with one, and fending off an army of<br>
depraved monkeys with a knife in the other hand. Threads are a pre-canned<br>
mechanism, but it would get awfully complicated making sure some sequences of<br>
steps in one thread happen without intervening interruption by another. Plus the<br>
question of who controls GL state. That, and racket threads don't work in<br>
Fluxus. :)<br></blockquote><div><br></div><div>Yes. The way that ChucK ( <a href="http://chuck.cs.princeton.edu/doc/language/time.html">http://chuck.cs.princeton.edu/doc/language/time.html</a> ) deals with this still seems sound to me. Essentially ChucK works like a single threat, but uses a syntax that looks like multi-threading (with threads having their own scope and state). This is then used to determine the calculation order of everything that happens. It looks like things happen at the same time, which is intuitively what we want, yet nothing ever does, which is what determinism "wants". Your system sounds "quite but not entirely unlike" that. There will probably be questions about actual and logical time that will need to be addressed or that might cause issues. Of course all instructions cost time to execute and we can easily ask for impossible things. Currently asking for things that are impossible isn't that easy, then one issue we can have is that a "frame" takes a very long time.</div>
<div><br></div><div>Also; good thing you warned about Racket threads as those were on my list of stuff to look into. I'm not a 100% sure about Fluxa's "(seq )" yet.</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I'm working on a script that uses this. First experience - explicitly maintained<br>
structures tend to disappear and everything is simpler. For tight stuff<br>
happening frame-to-frame it's faster to use `spawn-task' directly, but for<br>
big-picture things, this is... neat.<br>
<br>
Hope it's clearer now.<br><br></blockquote><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Got it. This actually sounds a lot like the "temporal recursion" that Dave was hinting at. To me this sounds like a very good idea. If I get to vote it's "full steam ahead". Good thinking and it looks like great work too.</div>
<div style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">If nobody minds, BTW, I'll call you "David" and keep calling Dave "Dave", even though he is actually called "David" as well. That should hopefully save confusion. </div>
<div style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Yours,</div><div><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">Kas.</span> </div>
</div></div>