March 2012 - Haskell-Cafe

Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
by Jason Dagit 20 Jun '12

20 Jun '12

In my experience the diamond of death is typically because: * You install package A that uses C-0.1 * Someone uploads C-0.2 to hackage * Later you 'cabal update', this does not rebuild A to use C-0.2, even though it could. * You install package B that uses C, and cabal builds it with C-0.2 * Now you want to build D that uses A and B, but A requires C-0.1 and B requires C-0.2, even though they could be rebuilt to use the same C. Typically, the constraints on A, B, and D would all accept the same version of C. Except that when they were compiled separately and C changed between building A and B, then the compiled versions become fixed on C-0.1 and C-0.2. It's true that it won't solve it in all cases, but in my experience using cabal-dev made the problem go away. I hope that clarifies. Jason On Fri, Feb 3, 2012 at 7:33 AM, Magicloud Magiclouds <magicloud.magiclouds(a)gmail.com> wrote: > Well, cabal-dev could not resolve the conflict of "the diamond". > Because the conflict is "depending different version at the SAME > time". > > On Fri, Feb 3, 2012 at 9:20 PM, Jason Dagit <dagitj(a)gmail.com> wrote: >> On Thu, Feb 2, 2012 at 9:54 PM, Magicloud Magiclouds >> <magicloud.magiclouds(a)gmail.com> wrote: >>> Hello, >>> As I recalled, ghc works in staticly link mode. So after one library >>> is compiled, all its build dependencies are useless. Lost, changed, >>> wheresoever, it does not matter. >>> Then why the problem of version conflicting exists? >> >> I'm not sure, but for me this problem has gone away by using cabal-dev >> to build everything. >> >> Jason > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com.

4 9

Fundeps and overlapping instances
by Simon Peyton-Jones 09 Jun '12

09 Jun '12

Oleg points out, and Martin also mentions, that functional dependencies appear to interact OK with overlapping instances, but type families do not. I this impression is mistaken, and I'll try to explain why in this message, in the hope of exposing any flaws in my reasoning. We can't permit overlap for type families because it is unsound to do so (ie you can break "well typed programs don't go wrong"). But if it's unsound for type families, it would not be surprising if it was unsound for fundeps too. (I don't think anyone has done a soundness proof for fundeps + local constraints + overlapping instances, have they?) And indeed I think it is. So the short summary of this message is: if it works for fundeps it works for type families, and vice versa. (NB this equivalence is not true about GHC's current implementation, however. GHC doesn't support the combination of fundeps and local constraints at all.) Such an equivalence doesn't argue against fundeps; I'm only suggesting the that the two really are very closely equivalent. I much prefer type families from a programming-style point of view, but that's a subjective opinion. Simon Imagine a system "FDL" that has functional dependencies and local type constraints. The big deal about this is that you get to exploit type equalities in *given* constraints. Consider Oleg's example, cut down a bit: class C a b | a -> b instance C Int Bool newtype N2 a = N2 (forall b. C a b => b) t2 :: N2 Int t2 = N2 True We end up type-checking (True :: forall b. C Int b => b). From the functional dependency we know that (b~Bool), so the function should typecheck. GHC rejects this program; FDL would not. But making use of these extra equalities in "given" constraints is quite tricky. To see why look first at Example 1: module X where class C a b | a -> b data T a where MkT :: C a b => b -> T a module M1 where import X instance C Int Char where ... f :: Char -> T Int f c = MkT c module M2 where import X instance C Int Bool g :: T Int -> Bool g (MkT x) = x module Bad where import M1 import M2 bad :: Char -> Bool bad = g . f This program is unsound: it lets you cast an Int to a Bool; result is a seg-fault. You may say that the problem is the inconsistent functional dependencies in M1 and M2. But GHC won't spot that. For type families, to avoid this we "eagerly" check for conflicts in type-family instances. In this case the conflict would be reported when compiling module Bad, because that is the first time when both instances are visible together. So any FDL system should also make this eager check for conflicts. What about overlap? Here's Example 2: {-# LANGUAGE IncoherentInstances #-} module Bad where import X -- Overlapping instances instance C Int Bool -- Instance 1 instance C a [a] -- Instance 2 f :: Char -> T Int f c = MkT c -- Uses Instance 1 g :: T a -> a g (MkT x) = x -- Uses Instance 2 bad :: Char -> Int bad = g . f Again, a seg fault if it typechecks. But will it? When typechecking 'g', we get a constraint (C a ?), where 'a' is a skolem constant. Without IncoherentInstances GHC would reject the program on the grounds that it does not know what instance to choose. But *with* IncoherentInstances it would probably go through, which is unsound. So IncoherentInstances has moved from causing varying dynamic behaviour to causing seg faults. Very well, so FDL must get rid of IncoherentInstances altogether, at least for classes that have functional dependencies (or that have superclasses that do). But at the moment GHC makes an exception for *existentials*. Consider Example 3: class C a b | a -> b -- Overlapping instances instance C Int Bool -- Instance 1 instance C a [a] -- Instance 2 data T where MkT :: C a b => a -> b -> T f :: Bool -> T f x = MkT (3::Int) x -- Uses Instance 1 g :: T -> T g (MkT n x) = MkT n (reverse x) -- Uses Instance 2 bad :: Bool -> T bad = g . f In the pattern match for MkT in g we have the constraint (C a b), where 'a' is existentially bound. So under GHC's current rules it'll choose the (C a [a]) instance, and conclude that (b ~ [a]). So it's ok to reverse x. But it isn't; see function bad! So to avoid unsoundness we must not choose a particular instance from an overlapping set unless we know, absolutely positively, that the other cases cannot match. (GHC's exception for existentials was introduced in response to user demand. Usually, overlapping instances are somehow semantically coherent, and with an existential we are *never* going to learn more about the instantiating type, so choosing the best available seems like a good thing to do.) But even nuking IncoherentInstances altogether is not enough. Consider this variant of Example 3, call it Example 4: module M where class C a b | a -> b instance C a [a] -- Instance 2 data T where MkT :: C a b => a -> b -> T g :: T -> T g (MkT n x) = MkT n (reverse x) -- Uses Instance 2 module Bad where import M instance C Int Bool -- Instance 1 f :: Bool -> T f x = MkT (3::Int) x -- Uses Instance 1 bad :: Bool -> T bad = g . f This is nasty. In module M we have only one instance declaration for C, so there's no overlap, and function g typechecks fine. Now module Bad adds an overlapping instance declaration and 'f' uses it; moreover, it's clear that the new instance declaration is the right one to use. It's not clear how to fix this. The only way I can think of is to insist that all the instances appear in a single module, so that you cannot add more "later". But that loses part of the point of overlap in the first place, namely to provide a generic instance and then later override it. So FDL must * embody eager checking for inconsistent instances, across modules * never resolve overlap until only a unique instance can possibly match * put all overlapping instances in a single module Type families already implement the first of these. I believe that if we added the second and third, then overlap of type families would be fine. (I may live to eat my words here.) I'd be interested to know what Chameleon does on these examples.

6 18

Install a script with Cabal?
by Ketil Malde 05 Jun '12

05 Jun '12

Hi, I have a small project that installs a couple of Haskell tools and a script that uses these. Cabal will of course build and install the Haskell programs, but how can I get Cabal to install the script as well? There's a host of UserHooks available¹, but it'd probably be better to have an example than to try to experiment with the right configuration. -k ¹ http://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distributio… -- If I haven't seen further, it is by standing in the footprints of giants

3 4

Offer to mirror Hackage
by Dan Knapp 24 Apr '12

24 Apr '12

With Hackage down, now seemed like a good time to push this issue again. It's such an important site to us that it's really rather a shame there are no mirrors of it. I have a personal-and-business server in a data center in Newark, with a fair chunk of bandwidth, which I'd like to offer for a permanent mirror. Is there interest in this? Who do I need to talk to for it to happen? Strategy-wise, I think the best approach is round-robin DNS, since that's transparent to the end user - everything would still appear at the URL it's at now, but behind-the-scenes magic would let things keep working when one or the other site is down. I haven't personally set up such a system before but I'm willing to take on the burden of figuring it out. So I have a better idea of what I'm signing up for, can anyone tell me how much disk space and how much bandwidth per month Hackage uses? I have a fair chunk of both, as I say, but I'd like to know in advance to ensure that things go smoothly. As for what I'd want in return for this, really nothing. I wouldn't say no to an unobtrusive mention somewhere on the site, but I'd be happy just knowing I'd given something back to the Haskell community, which has given a lot to me. -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

21 53

Google Summer of Code - Lock-free data structures
by Florian Hartwig 21 Apr '12

21 Apr '12

Hi everyone, I would like to do the GSoC project outlined in http://hackage.haskell.org/trac/summer-of-code/ticket/1608 One of Haskell's great strengths is its support for all kinds of concurrent and parallel programmming, so I think that the Haskell ecosystem would benefit from having a wider range of efficient concurrent data structures. Also, more selfishly, I remember reading the article in CACM last summer and thinking that the whole idea of updating data structures directly using atomic compare-and-swap was really cool, so I would love to have an excuse to play around with it. Some (initial) ideas for lock-free data structures worth implementing: 1. A lock-free priority queue, e.g. using the approach based on skip-lists explained in [2] 2. Stacks, see [1] and [3] 3. Hash tables [4] but if anyone has other suggestions, I would obviously happy to hear them. GSoC stretches over 13 weeks. I would estimate that implementing a data structure, writing tests, benchmarks, documentation etc. should not take more than 3 weeks (it is supposed to be full-time work, after all), which means that I could implement 4 of them in the time available and still have some slack. About me: My name is Florian Hartwig, I'm a fifth year (Master's) student in Computing Science at the University of Glasgow. I've been using Haskell for a bit more than two years now (both for university courses and my recreational programming) and I'm currently using it for my Master's project, so I won't have to spend any time learning the Haskell basics. I don't have any other plans for the summer that might conflict with the project. I'd be thankful for any thoughts, questions and suggestions. Cheers, Florian [1] http://cacm.acm.org/magazines/2011/3/105308-data-structures-in-the-multicor… [2] http://www.sciencedirect.com/science/article/pii/S0743731504002333 [3] http://dl.acm.org/citation.cfm?id=1007944 [4] http://dl.acm.org/citation.cfm?id=564881

10 28

Fwd: Now Accepting Applications for Mentoring Organizations for GSoC 2012
by Johan Tibell 20 Apr '12

20 Apr '12

Hi all, Anyone interested in acting as an admin for haskell.org this year? I'm afraid I won't have time. It's not that much work (filling in some information, sending out some emails, making sure things happen in time.) ---------- Forwarded message ---------- From: Carol Smith <carols(a)google.com> Date: Mon, Feb 27, 2012 at 11:47 AM Subject: Now Accepting Applications for Mentoring Organizations for GSoC 2012 To: Google Summer of Code Announce < google-summer-of-code-announce(a)googlegroups.com> Hi all, We're pleased to announce the applications for mentoring organizations for GoogleSummer of Code 2012 are now being accepted [1]. Please go Melange [2] to apply on behalf of your organization. Please note that the application period [3] closes on 9 March at 23:00 UTC. We will not accept any late applications for any reason. [1] - http://google-opensource.blogspot.com/2012/02/mentoring-organization-applic… [2] - http://www.google-melange.com [3] - http://www.google-melange.com/gsoc/events/google/gsoc2012 Cheers, Carol -- You received this message because you are subscribed to the Google Groups "Google Summer of Code Announce" group. To post to this group, send email to google-summer-of-code-announce(a)googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-announce+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-announce?hl=en.

3 7

Re: [Haskell-cafe] Too much inlining on text package
by wren ng thornton 08 Apr '12

08 Apr '12

On 3/16/12 12:22 PM, Aleksey Khudyakov wrote: > Disclaimer. I'm no expert in text internals. > > Because it's told to do so. This is an unfortunate feature of stream > fusion. It does eliminate intermediate data structures but it requires > that everything is inlined. There are ways of mitigating that, however. In particular, the standard style is to have things inline aggressively before stage 0 or 1, and then in the last stage to "inline" things back to an indirect call to the library. This is used ubiquitously in GHC's list fusion, and is essential for stream-fusion since the intermediate stream form is a pessimation when it can't partake in fusion. -- Live well, ~wren

6 8

Fail-back monad
by Alberto G. Corona 05 Apr '12

05 Apr '12

Hi Haskellers. In my package MFlow [1] I program an entire web navigation in a single procedure. That happened in the good-old WASH web application framework. The problem is the back button in the Browser. To go back in the code to the previous interactions when the data input does not match the expected because the user pressed the back button one or more times, i came across this Monad specimen,: that solves the problem. data FailBack a = BackPoint a -- will go back to this point | NoBack a . -- Normal outcome | GoBack -- "exception":: must go to the last backPoint newtype BackT m a = BackT { runBackT :: m (FailBack a ) } -- this monad nas a loop instance Monad m => Monad (BackT m) where fail _ = BackT $ return GoBack return x = BackT . return $ NoBack x x >>= f = BackT $ loop where loop = do v <- runBackT x case v of NoBack y -> runBackT (f y) -- business as usual BackPoint y -> do z <- runBackT (f y) case z of GoBack -> loop -- if x was a backpoint, then redirects the flow to this backpoint other -> return other GoBack -> return GoBack --propagate the signal back This monad does not perform exploration of alternatives as is the case of MonadPlus instances. It does not perform the kind of backtracking of "nondeterministic" three navigations in the Prolog style. It just go back to the last point where the computation can restart again in a sequence of actions. In this example: liftBackPoint f= BackT $ f >>= \x -> return $ BackPoint x test= runBackT $ do lift $ print "will not return back here" liftBackPoint $ print "will return here" n2 <- lift $ getLine lift $ print "second input" n3 <- lift $ getLine if n3 == "back" then fail "" else lift $ print $ n2++n3 Whenever the second input is "back" The procedure will go back to where liftBackPoint is. Otherwise, it will return the concatenation of the two inputs. If the underlying monad is an instance of MonadState, it can transport the state that caused the failure to the backpoint. Are there something similar? May it be functionally equivalent to something simpler or with more grounds? I looked at some exception monads out there, but they did not seems to share the same idea [1] http://haskell-web.blogspot.com.es/2012/02/web-application-server-with-stat…

3 6

Re: [Haskell-cafe] Fail-back monad
by oleg＠okmij.org 05 Apr '12

05 Apr '12

Alberto G. Corona wrote about a monad to set a checkpoint and be able to repeatedly go to that checkpoint and re-execute the computations following the checkpoint. http://haskell-web.blogspot.com.es/2012/03/failback-monad.html The typical example is as follows. > test= runBackT $ do > lift $ print "will not return back here" > liftBackPoint $ print "will return here" > n2 <- lift $ getLine > lift $ print "second input" > n3 <- lift $ getLine > if n3 == "back" > then fail "" > else lift $ print $ n2++n3 Let us first consider a slightly simplified problem, with a different signature for liftBackPoint. Rather than writing do liftBackPoint $ print "will return here" other_computation we will write do backPoint $ do lift $ print "will return here" other_computation In that case, backPoint will be implemented with the Exception or Error monad. For example, > backPoint :: Monad m => > ErrorT SomeException m a -> ErrorT SomeException m a > backPoint m = catchError m handler > where > handler e | Just RestartMe <- fromException e = backPoint m > handler e = throwError e -- other errors propagate up We designate one exception RestartMe as initiating the restart from the checkpoint. Other exceptions will propagate as usual. Obviously, if we are in IO or some MonadIO, we could use the regular exception-handling facilities: throw/catch. Suppose however that marking of the checkpoint should be a single action rather that exception-like handling form. Then we need the continuation monad: > type BackT r m a = ContT r (ErrorT SomeException m) a > > backPointC :: Monad m => ContT e (ErrorT SomeException m) () > backPointC = ContT (\k -> backPoint (k ())) (we have re-used the earlier backPoint). Incidentally, the continuation monad will be faster than BackT in the original article. Attentive reader must have noticed that backPointC is shift in disguise. Here is the complete code. > {-# LANGUAGE DeriveDataTypeable #-} > > module BackT where > > import Control.Monad.Trans > import Control.Monad.Error > import Control.Monad.Cont > import Control.Exception > import Data.Typeable > > > data RestartMe = RestartMe deriving (Show, Typeable) > instance Exception RestartMe > instance Error SomeException > > -- Make a `restartable' exception > -- (restartable from the beginning, that is) > -- We redo the computation once we catch the exception RestartMe > -- Other exceptions propagate up as usual. > > -- First, we use ErrorT > > backPoint :: Monad m => > ErrorT SomeException m a -> ErrorT SomeException m a > backPoint m = catchError m handler > where > handler e | Just RestartMe <- fromException e = backPoint m > handler e = throwError e -- other errors propagate up > > test1 = runErrorT $ do > lift $ print "will not return back here" > backPoint $ do > lift $ print "will return here" > n2 <- lift $ getLine > lift $ print "second input" > n3 <- lift $ getLine > if n3 == "back" > then throwError (toException RestartMe) > else lift $ print $ n2++n3 > > -- Obviously we can use error handling in the IO monad... > > -- Suppose we don't want backPoint that takes monad as argument. > -- We wish backPoint that is a simple m () action. > > -- We will use Cont monad then: That is, we use Cont + Error Monad > -- We reuse the old backPoint > > type BackT r m a = ContT r (ErrorT SomeException m) a > > backPointC :: Monad m => ContT e (ErrorT SomeException m) () > backPointC = ContT (\k -> backPoint (k ())) > > abort e = ContT(\k -> e) > > test2 :: BackT r IO () > test2 = do > liftIO $ print "will not return back here" > backPointC -- This line differs > liftIO $ print "will return here" -- (and the indentation on here) > n2 <- liftIO $ getLine > liftIO $ print "second input" > n3 <- liftIO $ getLine > if n3 == "back" > then abort $ throwError (toException RestartMe) > else liftIO $ print $ n2++n3 > > test2r = runErrorT $ runContT test2 return

2 2

Is this a correct explanation of FRP?
by Peter Minten 04 Apr '12

04 Apr '12

Hi, I've been trying to get my head around Functional Reactive Programming by writing a basic explanation of it, following the logic that explaining something is the best way to understand it. Am I on the right track with this explanation? Greetings, Peter Minten P.S. Sorry about the long mail, the explanation ended up a little longer than I originally expected. :) Document (with markdown formatting) follows: --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- This is an attempt to explain Functional Reactive Programming (FRP) enough to give a reader with no previous exposure to FRP an intuition what FRP is about. After reading this you should hopefully understand enough of FRP to understand the [reactive-banana](http://www.haskell.org/haskellwiki/Reactive-banana) examples. FRP has certain terms such as behavior, event and time-varying that can be confusing for people unfamiliar with it. I'll avoid these terms at first and will focus on spreadsheets and a generalization of spreadsheet cells (which I will call boxes). Later, once the most important concepts are explained, reactive-banana syntax will be introduced along with an example that demonstrates how to work with behaviors and events in reactive-banana. Finally some theory about time-varying functions and how events and behaviors can be implemented using pure functions by making time explicit should provide the necessary background to understand reactive-banana's haddock comments. The version of reactive-banana used here is [0.5.0.0](http://hackage.haskell.org/package/reactive-banana-0.5.0.0). Reactive Programming for the Masses: The Spreadsheet ==================================================== Spreadsheets are something we all (for certain values of we) know about. Let's talk about a typical, simplified, spreadsheet. We have a list of products that we sell and want to compute their price with the Value Added Tax (VAT) added. We might have cells A1 to A10 contain the raw prices of our products and cell B1 contain the current VAT rate (say 19 for a 19% VAT). In cells C1 to C10 we'd like to see the prices including VAT. In cell C1 we'd have a formula: `=A1*(1+B1/100)`, in cell C2 `=A2*(1+B1/100)`, etc. So if A1 contains $100 C1 would contain $119. But what if the government, in it's eternal quest to reduce the budget deficit, raises the VAT rate? We'd adjust cell B1, just change it to 20. And like magic all the C cells are updated. Though this may seem mundane what we've just seen is actually a very good example of reactive programming. We didn't tell the C cells to update; they updated on their own because a value they depend on changed. >From Cells to Boxes: Generalizing the Spreadsheet ================================================= Spreadsheets are nice, but if we want to truly get a feel for FRP we'll have to think beyond them. If we look at a spreadsheet at an abstract level it pretty much consists of cells of two types: value cells (`19`) and formula cells (`=A1*(1+B1/100)`). Let's lose the reference to spreadsheets and talk about boxes. Say, for now, that there are two kinds of boxes: formula boxes and value boxes. Both support a "get" operation that returns a value. Value boxes additionally support a "set" operation that sets the value. Formula boxes can contain any kind of pure function. They can also refer to the values of other boxes (both formula and value boxes). Value boxes don't have a function inside them, they have a value. The translation of our VAT spreadsheet would be something like a formula box *fIncl1* containing the expression `get(vExcl1) * (1 + get(vVat) / 100)`. This expression uses two value boxes: *vExcl1* and *vVat*. We could also write *fIncl1* using a helper formula box *fVat*. Let *fVat* have the formula `1 + get(vVat) / 100` and *fIncl1* have the formula `get(vExcl1) * get(vVat)`. I'll use `:=` for this kind of definition, the `:=` is there to remind you that this isn't Haskell. It's important to note that any kind of value may be put into value boxes, including IO actions and functions. Try doing this with a spreadsheet: `fIncls := [get(ve) * get(vVat) | ve <- vExcls]`. Or this: `fIncl1 := apply(get(vVatFunc), get(vExcl1))`. If you're wondering why I'm not using Haskell syntax, it's to focus on the meaning of boxes rather than what the functions and combinators mean. That said, this pseudo-imperative syntax is on its way out as it's getting too clunky (that `apply` function is really just ugly). For a quick peek ahead the last few examples would be something like this in reactive-banana: fIncls = map (\ve -> (*) <$> ve <*> fVat) vExcls fIncl1 = fVatFunc <*> vExcl1 Events ====== Let's say we want to build the worlds worst synthesizer. We have 7 buttons: "a", "b", "c", "d", "e", "f" and "g". Our output is generated by sampling a box twice per second and playing the frequency in the box until the next sample is taken. This can't be expressed with the crude formula and value boxes system we've had so far. There is no way to express key presses in that system, a key press isn't like changing a value, it's something that occurs on a specific point in time but after it occurs it's forgotten (your keyboard doesn't remember key strokes, at least mine doesn't). In this new system we'll forget about formula boxes and value boxes and introduce event boxes. Event boxes are like formula boxes in that they can refer to the value of other boxes. Event boxes can also react to events. Events can be thought of like signals in something like D-Bus. Multiple things (event boxes) can listen to them and do something once a specific event is fired (triggered). Every event has a value associated with it. Sometimes the value isn't important because the fact that the event has occurred is what's interesting but often we do want to know the value. Events come in streams. When we say event box *b1* changes to the value of event *e1* when it receives that event we're actually saying that whenever an event from the stream of events we colloquially call *e1* comes *b1* changes to the value of that event. Yes, that's confusing so I'll try to be precise. Just remember that when I refer to something like *e1* when defining an event box it's always to a stream of events, never a specific event. If you're puzzled by the stream just think of it as an acknowledgement that a certain kind of event can occur multiple times. It actually goes a lot deeper than that, involving those confusing `[(t, e)]` types, but for now just remembering that a kind of event can occur multiple times with possibly different values is good enough. Events have values and we can use that to chose to do something only for events with some value. So not only can we determine which streams of events we'll do something with when defining an event box, we can also determine for what values of events we'll do something. For example if we have an event that directly sets our synthesizer frequency we can apply a filter that only allows events with frequencies that are pleasant to the human ear. Some Reactive-Banana syntax =========================== Expressing event handling with the pseudo-code I've used before is tricky and gets near impossible soon. So it's a good thing that once you've understood or at least got a basic idea of the concepts of event streams and event boxes the syntax of reactive-banana starts to make sense. In this section I'll explain the most fundamental functions and operators. If you're reading the [reactive-banana 0.5 haddocks](http://hackage.haskell.org/package/reactive-banana-0.5.0.0) there are a few things to keep in mind. The first is that what I've called an event box in the previous section is called a Behaviour in reactive-banana. To avoid confusion I'll stop using the term event box from here on. In the reactive-banana haddocks you'll find a lot of references to time-varying functions and lists involving time variables. Just ignore those, they're important but we'll get to them later. As a general rule just ignore what you don't understand. You'll also notice a `t` parameter on the `Event` and `Behavior` types. It's basically similar to the `s` parameter for `STRef`, it's a trick to use the type system to prevent constructs that would result in undefined or incorrect behavior. Just ignore it. For understanding the next sections you'll need to know about a basic subset of reactive-banana which I'll explain here. First up: event streams. Events ------ Event streams are represented by the type Event in reactive-banana. The type `Event t Int` means a stream of events carrying Int values. There are three basic things you can do with just event streams. You can transform the events in them, you can filter in events in them and you can combine the event streams. Transforming an event stream means changing the values carried by the events in them. As this is *Functional* Reactive Programming the streams themselves are not changed. When you transform a stream you create a new stream. Whenever an event in the old stream is fired an event in the new stream is also fired, but with a different value. Transforming an event stream is done primarily by good old fmap. The expression ``show `fmap` eInt`` (or with the (`<$>`) operator `show <$> eInts`) with *eInt* having the type `Event t Int` creates a new event stream of the type `Event String` with the int in every event in the original stream being a string in the new stream. To replace the value of an event (if the event doesn't carry a useful value) just use (`<$`): `"MOO!" <$ eWhatever` causes every value in the stream eWhatever to be replaced by MOO!. Like (`<$>`) this is an operator from Control.Applicative. Filtering is done using the `filterE` function. When you filter an event stream you create a new event stream with the same associated values but which doesn't contain all the events from the original stream. To only deal with events with positive integers you can create a filtered stream using ``filterE (>= 0) eInt``. Combining event streams creates a new event stream with all the events from both streams. So if you combine *eOne* and *eTwo* into *eThree* there will be an event in *eThree* for every event in *eOne* and for every event in *eTwo*. Combining is done with the union function: ``eThree = eOne `union` eTwo``. Beware however that when events come in at the same time things can get a little tricky, you'd have to wonder in what order the events are processed. Reactive-banana contains several functions to handle simultaneous events. For the purpose of this document we'll do the easiest thing and ignore simultaneous events. In real world code you would need to think about it. Behaviors --------- To create a behavior (event box) in reactive-banana you'll typically use one of two functions: `stepper` and `accumB`. Both work with an initial value and an event stream. The difference is that when an event occurs `stepper` changes the value of the behavior to the value in the event while `accumB` applies the function in the event to the value of the behavior. eNewVal :: Event t Int bSet :: Behavior t Int bSet = stepper 0 eNewVal eUpdater :: Event t (Int -> Int) bUpdated :: Behavior t Int bUpdated = accumB 0 eUpdater The expression `bSet = stepper 0 eNewVal` creates a behavior named *bSet* with initially value 0. Once an event from the *eNewVal* stream comes in the value of *bInt* changes to the value in that event. So if an event comes in with value 2 the value of bSet becomes 2. On the other hand the expression `bUpdated = accumB 0 eUpdater` makes *bUpdated* a behavior with initially the value 0 but which gets updated (modified) whenever an event comes in. If an event comes in with value (+1) (a slice, so `\x -> x + 1`) and the current value of *bUpdated* is 1 the new value becomes 2. That's basically it for behaviors. Well, there's a third way to create behaviors: using `pure`. To create a behavior with the value 1 which doesn't change at all use `pure 1`. In case you didn't know, for applicative functors (which behaviors are) `pure` is what `return` is for monads. To create a behavior that's depends on old behaviors (`f3 := get(f1) + get(f2)` in our old formula box syntax) we have to use applicative functor functions in reactive-banana. There is unfortunately no option to use monad syntax. To express that the value of *b3* is the sum of the value of *b1* and the value of *b2* we write: `b3 = (+) <$> b1 <*> b2`. Example: The Worlds Worst Synthesizer ===================================== Now for an example. We'd like to create a synthesizer. The synthesizer will use our keyboard for input, which we notice through a stream of events called *eKey* with as associated value a Char containing the key that was pressed. Something outside our program (and scope of discussion) samples the behavior *bNote* every 100ms and plays the tone currently in there until the next sample time. To avoid getting caught up in music theory (read: I'm lazy and can't be bothered to look up tone frequencies) the note to play is expressed as an algebraic data type. type Octave = Int data Pitch = PA | PB | PC | PD | PE | PF | PG data Note = Note Octave Pitch -- Type signature for the key event, it comes from outside our -- system. eKey :: Event t Char You'll notice the octave. To change the octave we'll use the '-' and '+' keys. To set the pitch we'll use the 'a'..'g' keys on the keyboard. Never mind that it's really annoying to play with those keys as they're scattered all over the keyboard, this is about the FRP logic not practicality. Those chars in the *eKey* event stream need to be translated to pitches. Here's one way to do that. ePitch :: Event t Pitch ePitch = (PA <$ filterE (=='a') eKey) `union` (PB <$ filterE (=='b') eKey) `union` ... (PG <$ filterE (=='g') eKey) The "trouble" here is that we're filtering the stream multiple times, not very efficient. Here's a better way. table = [('a', PA), ('b', PB), ..., ('g', PG)] ePitch = filterJust $ (\e -> lookup e table) <$> eKey The `filterJust` function is a simple helper in reactive-banana. It filters out `Nothing` events and returns the value inside the `Just` constructor for `Just` events. To get *ePitch* we first look up the characters in the translation table and then remove all events who's chars aren't in the table, removing the `Just` wrapper from events who's chars are in the table at the same time. The *bNote* behavior will not use these events directly, instead *bOctave* and *bPitch* will each store part of the note and *bNote* will combine the information. eOctUp, eOctDown :: Event t Char eOctUp = filterE (=='+') eKey eOctDown = filterE (=='-') eKey bOctave :: Behavior t Octave bOctave = accumB 0 $ ((+1) <$ eOctUp) `union` ((subtract 1) <$ eOctDown) bPitch :: Behavior t Pitch bPitch = stepper PC ePitch bNote :: Behavior t Note bNote = Note <$> bOctave <*> bPitch If you understand what's going on here you should have a basic idea of what FRP is in practice. There are of course considerations in the real world that we've skipped over here, such as how to get the keyboard event and how to play the sounds. To get a better idea of what FRP in the real world looks take a look at the [reactive-banana examples](http://www.haskell.org/haskellwiki/Reactive-banana/Examples), they should be easy to follow. When following those examples you'll come across the (`<@`) and (`<@>`) operators. I'll give a short introduction here to make it easier to understand the examples. The (`<@`) operator is used like this: `e2 = b1 <@ e1`, if an event in stream *e1* comes in the value of that event is replaced in the *e2* stream by whatever value is in *b1* at the time. The (`<@>`) operator is used in much the same way, but it doesn't replace the value from *e1* outright but uses it to compute a new value. bOne :: Behavior t Int bOne = pure 1 bPlusOne :: Behavior t (Int -> Int) bPlusOne = pure (+1) eAlwaysOne, ePlusOne :: Event t Int eAlwaysOne = bOne <@ eWhatever ePlusOne = bPlusOne <@> eInt Time-varying values and functions ================================= If you've read about FRP before you're likely to have come across the term "time-varying function". This sounds difficult, but once you understand the basics of behaviors and events it's really no big deal. Here's the clue: a behavior contains a value, but the value can change. Therefore at different points in time a behavior can have different values. So we could say that a behavior has a value that varies in time. We could also throw away the concept of boxes and say a behavior *is* a value that varies in time. This is more correct, those boxes are helpful as teaching concepts but once we talk directly about time they are no longer needed. So, a time-varying value is simply a behavior as behaviors can have different values at different points in time. A time-varying function is also just a behavior, one where the value is a function (functional programming 101: the clue to every riddle is that functions are values). To go further down the rabbit hole a time-varying value can actually be thought of as a function by making time explicit. If a behavior has value 1 up to the 30th's second and from that point forward value 2 we could express the behavior as: `\t -> if t < 30 then 1 else 2`. This is important: by making time explicit we can reason about behaviors as if they were pure functions. While in practice we're dealing with applicative functors (or in other libraries monads or arrows) we can think of behaviors as pure functions. Real world behaviors aren't as simple as from 30 seconds onwards change to value 2. They interact with events. So to express such behaviors as pure functions events need to be expressed in a way that works for pure functions. This is where the `[(t,e)]` type comes in. We can see events as a list of values at certain points in time, for example `[(10, 1), (20, 2), (30, 3)]` for events that occur on second 10, 20 and 30 with values 1, 2 and 3 respectively. When viewing events in such a way it becomes easy to create a behavior that changes to whatever value was last: type Time = Int stepped :: [(Time, Int)] -> Time -> Int stepped es t = case takeWhile (\(t', _) -> t' <= t) es of [] -> 0 xs -> snd (last xs) For once this is actually runnable code. If we invoke it as `stepped [(10,1),(20,1),(30,1)] 2` the result is 0, if we invoke it as `stepped [(10,1),(20,1),(30,1)] 12` the result is 1, as expected. Stepped sounds a lot like stepper and we can create that function by making a few small adjustments. type Time = Int stepper :: a -> [(Time, a)] -> (Time -> a) stepper d es = \t -> case takeWhile (\(t', _) -> t' <= t) es of [] -> d xs -> snd (last xs) If you understand this bit, why behaviors and events can be expressed by making time explicit you have a good intuition of what FRP is. Good luck on your endeavors in FRP land.

6 12