|
FRP.Yampa.Utilities | Portability | portable | Stability | provisional | Maintainer | nilsson@cs.yale.edu |
|
|
|
Description |
Derived utility definitions.
ToDo:
- Possibly add
impulse :: VectorSpace a k => a -> Event a
But to do that, we need access to Event, which we currently do not have.
- The general arrow utilities should be moved to a module
FRP.Yampa.Utilities.
- I'm not sure structuring the Yampa "core" according to what is
core functionality and what's not is all that useful. There are
many cases where we want to implement combinators that fairly
easily could be implemented in terms of others as primitives simply
because we expect that that implementation is going to be much more
efficient, and that the combinators are used sufficiently often to
warrant doing this. E.g. switch should be a primitive, even though
it could be derived from pSwitch.
- Reconsider recur. If an event source has an immediate occurrence,
we'll get into a loop. For example: recur now. Maybe suppress
initial occurrences? Initial occurrences are rather pointless in this
case anyway.
|
|
|
Documentation |
|
|
|
arr3 :: Arrow a => (b -> c -> d -> e) -> a (b, c, d) e | Source |
|
|
arr4 :: Arrow a => (b -> c -> d -> e -> f) -> a (b, c, d, e) f | Source |
|
|
arr5 :: Arrow a => (b -> c -> d -> e -> f -> g) -> a (b, c, d, e, f) g | Source |
|
|
|
|
|
|
lift2 :: Arrow a => (c -> d -> e) -> a b c -> a b d -> a b e | Source |
|
|
lift3 :: Arrow a => (c -> d -> e -> f) -> a b c -> a b d -> a b e -> a b f | Source |
|
|
lift4 :: Arrow a => (c -> d -> e -> f -> g) -> a b c -> a b d -> a b e -> a b f -> a b g | Source |
|
|
lift5 :: Arrow a => (c -> d -> e -> f -> g -> h) -> a b c -> a b d -> a b e -> a b f -> a b g -> a b h | Source |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Produced by Haddock version 2.3.0 |