The Animas fork is something I did, to fix up some annoyances in Yampa. It's otherwise the same.

What are the annoyances you are talking about? Are you describing somewhere why you needed to fork Yampa? (Documentation maybe? I saw you added to Animas the documentation on the functions that Yampa missed. ) 2011/7/15 Edward Amsden

On Fri, Jul 15, 2011 at 12:56 AM, Jason Dagit wrote:

...

On Thu, Jul 14, 2011 at 5:04 PM, Ertugrul Soeylemez wrote:

...

Hello all,

...

...

I really like the way Animas (fork of Yampa) represents reactive systems, and I would love to write some of my simulations using it.

Hi.

The Animas fork is something I did, to fix up some annoyances in Yampa. It's otherwise the same.

...

...

Unfortunately most of what I want to do requires dynamic systems, which can be boiled down to me believing to need an ArrowChoice instance for the SF arrow, because I have to choose between different signal paths depending on the input signal or events.

Animas appears to be only suitable for robot-like systems with specific, predefined actors.

Is there anything I can do about it? Is it difficult to write the ArrowChoice instance?

Recall that signals in Animas/Yampa are conceptually continuous, which means that an ArrowChoice instance would need to make a choice at every instant. This would expose the underlying sample rate. So, no, ArrowChoice doesn't conceptually fit in Animas/Yampa.

...

...

Or is there a different solution, which I overlooked? If I understand the thesis about the Frag game correctly it uses rSwitch, or rpSwitch, to make a dynamic switch: http://www.haskell.org/haskellwiki/Yampa/rSwitch http://haskell.org/haskellwiki/Frag The switching combinators are the correct solution for dynamic systems.

-- Edward Amsden Student Computer Science Rochester Institute of Technology www.edwardamsden.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe