Vaguely about Yump's switch circuits

Question

There are several diagrams of Yump switches:

http://www.haskell.org/haskellwiki/Yampa/switch

http://www.haskell.org/haskellwiki/Yampa/rSwitch

http://www.haskell.org/haskellwiki/Yampa/kSwitch

(etc.).

I found that switch , the only diagram with a description, is the easiest to understand. For the rest, it seems difficult to follow similar symbols to read the diagrams. For example, to try to read rSwitch with the characters used in the switch , it could be:

Be a recursive SF that always provides a signal of type 'in' and returns a signal of type 'out'. Start with the initial SF of the same but someone outside the switch function (square? [Cond]) can also pass the new SF through the Event (type Event (SF in out) on the signature) until the condition is met (for '?' To [cond ] square). In the event of an event, Yampa will use the new SF and not the existing one. This process is recursive because '?' (Cannot get it from the diagram, except that the rSwitch signature seems recursive).

And after I look at the source of rSwitch , it looks like it uses switch to switch to the same init SF recursively until t fired (as described in the diagram, although I don’t see what the special will do t in the source code).

In Yampa Arcade, he explains dpSwitch code and an example. And the Frag game document also uses dpSwitch . However, rSwitch missing from this tutorial. Therefore, I really do not know how to use r- or k- serial switches, and in which cases we will need them.

Answer 1

All switch functions are ways to change the signal function to behave like another signal function. I personally think that the Yampa diagrams are somewhat difficult to parse, but the type signatures of the various switches give a good idea of ​​how to understand them. When you understand type signatures, diagrams become much clearer. switch itself is the most basic:

 switch :: SF a (b, Event c) -> (c -> SF ab) -> SF ab 

If we look at the type, it will tell you exactly what it does: it requires SF sf and the SF sfg generator. sf creates values ​​of type (b, Event c) , and the input for the signal function generator also has type c . Thus, whenever the sf event occurs, SF switches to the result of the SF generator. Until an event occurs, the received SF will return the value of the original SF.

This idea is also used in rswitch and kswitch , but in a slightly different way.

---

rswitch : This is called an “external switch,” which means the SF will switch without any analysis of its input or output. Let's look at a signature like:

 rswitch :: SF ab -> SF (a, Event (SF ab)) b 

It takes one SF, which takes type a as input and outputs values ​​of type b . rswitch creates a new SF, which also produces output b , but accepts additional input of type Event (SF ab) . Note that the type of event value matches the input type. This means that whenever an event occurs, this SF switches to this event value. However, the type SF remains SF (a, Event (SF ab)) b . This means that SF can receive additional events with new SFs, which will affect the behavior of the general SF. To do this, you can use the AI ​​behavior in the game:

 moveFollowTarget :: SF TargetPosition Velocity moveShootTarget :: SF TargetPosition Velocity moveIdle :: SF TargetPosition Velocity aiMovement :: SF (TargetPosition, Event (SF TargetPosition Velocity)) Velocity aiMovement = rswitch moveIdle -- Initially idle... aiMovementManager :: SF a (Event (SF TargetPosition Velocity)) aiMovementManager = ... whatever ... 

Here, aiMovementManager will fire an event whenever the behavior of the AI ​​movement should change, and the value of the event will be SF, which the movement should change.

---

kswitch : This is called an intrinsic switch , as the contents of the SF are parsed to find out what the correct switch should be. Let's move on to the type signature

 kswitch :: SF ab -> SF (a, b) (Event c) -> (SF ab -> c -> SF ab) -> SF ab 

Here kswitch takes three arguments, sf , analyzer and mapping . sf is just standard SF with inputs of type a and outputs of type b . sf is how the signal behaves initially. analyzer is an SF that accepts sf input and output and may or may not trigger some kind of event whose value is of type c . If it does not fire the event, then nothing happens, and SF continues to behave like sf . If it fires an event, then both sf and the value of the event are passed to mapping , which defines the new SF to switch to. kswitch is useful in changing the way systems behave based on their outputs.

One example where this is useful is the algorithm for avoiding TCP congestion . Here we look at whether we are losing network packets or increasing or decreasing the speed with which we request data.