[Fluxus] Continuations, take 1

Kassen signal.automatique at gmail.com
Thu Feb 17 11:06:58 PST 2011


Oops. I should have used "reply to all".

Let me try again and be more complete this time;



It's a problem with waiting for stuff to happen, I think. To multiplex
> separate
> logically continuous, but not temporally coherent streams of steps, you
> typically have to ride a monocycle juggling with one, and fending off an
> army of
> depraved monkeys with a knife in the other hand. Threads are a pre-canned
> mechanism, but it would get awfully complicated making sure some sequences
> of
> steps in one thread happen without intervening interruption by another.
> Plus the
> question of who controls GL state. That, and racket threads don't work in
> Fluxus. :)
>

Yes. The way that ChucK (
http://chuck.cs.princeton.edu/doc/language/time.html ) 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.

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.


I'm working on a script that uses this. First experience - explicitly
> maintained
> structures tend to disappear and everything is simpler. For tight stuff
> happening frame-to-frame it's faster to use `spawn-task' directly, but for
> big-picture things, this is... neat.
>
> Hope it's clearer now.
>
> 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.

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.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20110217/9d6d35b9/attachment-0001.html>


More information about the Fluxus mailing list