switch package:Yampa

Basic switch. By default, the first signal function is applied. Whenever the second value in the pair actually is an event, the value carried by the event is used to obtain a new signal function to be applied *at that time and at future times*. Until that happens, the first value in the pair is produced in the output signal. Important note: at the time of switching, the second signal function is applied immediately. If that second SF can also switch at time zero, then a double (nested) switch might take place. If the second SF refers to the first one, the switch might take place infinitely many times and never be resolved. Remember: The continuation is evaluated strictly at the time of switching!
Switches allow you to change the signal function being applied. The basic idea of switching is formed by combining a subordinate signal function and a signal function continuation parameterised over some initial data. For example, the most basic switch has the following signature:
switch :: SF a (b, Event c) -> (c -> SF a b) -> SF a b
which indicates that it has two parameters: a signal function that produces an output and indicates, with an event, when it is time to switch, and a signal function that starts with the residual data left by the first SF in the event and continues onwards. Switching occurs, at most, once. If you want something to switch repeatedly, in general, you need to loop, or to switch onto the same signal function again. However, some switches, explained below, are immediate (meaning that the second SF is started at the time of switching). If you use the same SF that originally provoked the switch, you are very likely to fall into an infinite loop. In those cases, the use of dSwitch or --> may help. Switches vary depending on a number of criteria:
  • Decoupled vs normal switching (d): when an SF is being applied and a different SF needs to be applied next, one question is which one is used for the time in which the switching takes place. In decoupled switching, the old SF is used for the time of switching, and the one SF is only used after that. In normal or instantaneous or coupled switching, the old SF is discarded immediately and a new SF is used for the output already from that point in time.
  • How the switching event is provided ( /r/k): normally, an Event is used to indicate that a switching must take place. This event can be part of the argument SF (e.g., switch), it can be part of the input (e.g., rSwitch), or it can be determined by a second argument SF (e.g, kSwitch).
  • How many SFs are being handled ( /p/par): some combinators deal with only one SF, others handle collections, either in the form of a Functor or a list ('[]').
  • How the input is router (B/Z/ ): when multiple SFs are being combined, a decision needs to be made about how the input is passed to the internal SFs. In some cases, broadcasting is used to pass the same input to all internal SFs. In others, the input is itself a collection, and each element is passed to one internal SF (i.e., zipping). In others, an auxiliary function is used to decide how to route specific inputs to specific SFs in the collection.
These gives a number of different combinations, some of which make no sense, and also helps determine the expected behaviour of a combinator by looking at its name. For example, drpSwitchB is the decoupled (d), recurrent (r), parallel (p) switch with broadcasting (B).
Switch with delayed observation. By default, the first signal function is applied. Whenever the second value in the pair actually is an event, the value carried by the event is used to obtain a new signal function to be applied *at future times*. Until that happens, the first value in the pair is produced in the output signal. Important note: at the time of switching, the second signal function is used immediately, but the current input is fed by it (even though the actual output signal value at time 0 is discarded). If that second SF can also switch at time zero, then a double (nested) switch might take place. If the second SF refers to the first one, the switch might take place infinitely many times and never be resolved. Remember: The continuation is evaluated strictly at the time of switching!
kSwitch with delayed observation. Applies the first SF until the input signal and the output signal, when passed to the second SF, produce an event, in which case the original SF and the event are used to build an new SF to switch into. The switch is decoupled (dSwitch). See https://wiki.haskell.org/Yampa#Switches for more information on how this switch works.
Parallel switch with delayed observation parameterized on the routing function. The collection argument to the function invoked on the switching event is of particular interest: it captures the continuations of the signal functions running in the collection maintained by dpSwitch at the time of the switching event, thus making it possible to preserve their state across a switch. Since the continuations are plain, ordinary signal functions, they can be resumed, discarded, stored, or combined with other signal functions.
Decoupled parallel switch with broadcasting (dynamic collection of signal functions spatially composed in parallel). See dpSwitch. For more information on how parallel composition works, check https://www.antonycourtney.com/pubs/hw03.pdf
Decoupled parallel switch with broadcasting (dynamic collection of signal functions spatially composed in parallel). See dpSwitch. For more information on how parallel composition works, check https://www.antonycourtney.com/pubs/hw03.pdf
Recurring switch with delayed observation. Uses the given SF until an event comes in the input, in which case the SF in the event is turned on, until the next event comes in the input, and so on. Uses decoupled switch (dSwitch). See https://wiki.haskell.org/Yampa#Switches for more information on how this switch works.
Recurring parallel switch with delayed observation parameterized on the routing function. Uses the given collection of SFs, until an event comes in the input, in which case the function in the Event is used to transform the collections of SF to be used with rpSwitch again, until the next event comes in the input, and so on. The routing function is used to decide which subpart of the input goes to each SF in the collection. This is the parallel version of drSwitch.
Decoupled recurring parallel switch with broadcasting. Uses the given collection of SFs, until an event comes in the input, in which case the function in the Event is used to transform the collections of SF to be used with rpSwitch again, until the next event comes in the input, and so on. Broadcasting is used to decide which subpart of the input goes to each SF in the collection. This is the decoupled version of rpSwitchB. For more information on how parallel composition works, check https://www.antonycourtney.com/pubs/hw03.pdf
Decoupled recurring parallel switch with "zip" routing. Uses the given list of SFs, until an event comes in the input, in which case the function in the Event is used to transform the list of SF to be used with rpSwitchZ again, until the next event comes in the input, and so on. Zip routing is used to decide which subpart of the input goes to each SF in the list. See rpSwitchZ and drpSwitch. For more information on how parallel composition works, check https://www.antonycourtney.com/pubs/hw03.pdf
Call-with-current-continuation switch. Applies the first SF until the input signal and the output signal, when passed to the second SF, produce an event, in which case the original SF and the event are used to build an new SF to switch into. See https://wiki.haskell.org/Yampa#Switches for more information on how this switch works.
Parallel switch parameterized on the routing function. This is the most general switch from which all other (non-delayed) switches in principle can be derived. The signal function collection is spatially composed in parallel and run until the event signal function has an occurrence. Once the switching event occurs, all signal function are "frozen" and their continuations are passed to the continuation function, along with the event value.
Parallel switch (dynamic collection of signal functions spatially composed in parallel) with broadcasting. See pSwitch. For more information on how parallel composition works, check https://www.antonycourtney.com/pubs/hw03.pdf
Parallel switch (dynamic collection of signal functions spatially composed in parallel). See pSwitch. For more information on how parallel composition works, check https://www.antonycourtney.com/pubs/hw03.pdf
Recurring switch. Uses the given SF until an event comes in the input, in which case the SF in the event is turned on, until the next event comes in the input, and so on. See https://wiki.haskell.org/Yampa#Switches for more information on how this switch works.
Recurring parallel switch parameterized on the routing function. Uses the given collection of SFs, until an event comes in the input, in which case the function in the Event is used to transform the collections of SF to be used with rpSwitch again, until the next event comes in the input, and so on. The routing function is used to decide which subpart of the input goes to each SF in the collection. This is the parallel version of rSwitch.
Recurring parallel switch with broadcasting. Uses the given collection of SFs, until an event comes in the input, in which case the function in the Event is used to transform the collections of SF to be used with rpSwitch again, until the next event comes in the input, and so on. Broadcasting is used to decide which subpart of the input goes to each SF in the collection. See rpSwitch. For more information on how parallel composition works, check https://www.antonycourtney.com/pubs/hw03.pdf
Recurring parallel switch with "zip" routing. Uses the given list of SFs, until an event comes in the input, in which case the function in the Event is used to transform the list of SF to be used with rpSwitchZ again, until the next event comes in the input, and so on. Zip routing is used to decide which subpart of the input goes to each SF in the list. See rpSwitch. For more information on how parallel composition works, check https://www.antonycourtney.com/pubs/hw03.pdf