Preventing endless loops in Yampa/Animas with SF's depending on each other

Question

I'm trying to understand how this functional reactive programming works, and I have run into a problem. I am trying to create a boid simulation, but I'm starting out slowly, and I have for now defined a boid as a function taking a starting position and creating a signal function from a position to a position, where the input is the point it is moving towards and the output is the current position:

type Position2 = Vector2 Float

boid :: Position2 -> SF Position2 Position2
boid s = loop (arr (uncurry seek) >>> integral >>> arr (^+^ s) >>> arr dup)

the seek function takes two inputs (because of the loop). The current position and the target position. Then it just creates a vector pointing from the current position towards the target position with a magnitude of 50 i.e. the velocity. Then the velocity is integrated and the starting position is added. In the end the signal is split into two, so one can become the output and the other can loop back into the seek function.

Now i can define boids like this:

aBoid = constant (vector2 500 500) >>> (boid (vector2 600 60))
bBoid = aBoid >>> (boid (vector2 3 4))

Here aBoid seeks towards the point (500, 500) and bBoid seeks towards aBoid.

My problem is, when i want the two boids to seek toward each other. When i do this:

aBoid = bBoid >>> (boid (vector2 600 60))
bBoid = aBoid >>> (boid (vector2 3 4))

The program just prints: ProgramName: <<loop>> which I assume means that it goes into an endless loop.

I have also tried to use the par function like this:

sim :: SF a [Position2]
sim = loop (arr snd >>> par route [boid (vector2 10 10), boid (vector2 100 100)] >>> arr dup)

here the route function just maps the output of each boid to the input of another one (like zip, but with an offset of 1)

This also gives the <<loop>> message.

I would think that having objects depend on the state of each other should be a pretty common problem when dealing with reactive systems, so I hope there is some elegant solution.

I should add that I find this FRP thing very hard and often confusing, so I'm not really sure if i even make sense at all ;)

Answer 1

So with a little help from ehird i came up with something that works.

The code is as follows(here using 3 boids instead of 2):

sim :: SF a [Position2]
sim = loopPre [zeroVector, zeroVector, zeroVector] (
    arr snd >>>
    par route [boid (vector2 10 10), boid (vector2 100 400), boid (vector2 500 500)] >>>
    arr dup)

Here the route function works the same as the one i described in the question.

By using loopPre instead of loop i can give each boid a starting position, which solves the problem. I think the reason ehird's solution did not work, was that some plumbing is required when running several signal functions in parallel, which the par function takes care of.

An answer from someone who is 100% sure whats going on would be appreciated :)

Edit

This implementation of sim is a little prettier:

sim :: Int -> SF a [Position2]
sim num = loopPre (take num (repeat zeroVector)) (
    arr snd >>>
    par route (randomBoids num) >>>
    arr dup)

Where randomBoids num generates num random boids.

Answer 2

I'm not really familiar with Yampa/Animas, but it seems like the problem is essentially that you have a recursion with no base case; you've described the evolution of the system, but not how it starts out.

How about:

aBoid = bBoid >>> boid (vector2 600 60) >>> iPre (vector2 0 0)
bBoid = aBoid >>> boid (vector2 3 4)

so that aBoid starts out at (0,0), and then the feedback loop begins the next instant? This is assuming my understanding of iPre is correct...

(The pipeline may be easier to understand if you imagine it with (.), the flipped version of (>>>).)