Thanks, Bob. I agree entirely. FRP is a replacement for the imperative
(IO) way of thinking. The IO exposed in Reactive is solely for making
legacy adapters. Applications would have no visible IO. Why? Because
(non-toy) imperative programming has intractable denotation and hence is
troublesome to compose and reason about. - Conal
On Mon, Mar 23, 2009 at 3:48 PM, Thomas Davie
On 23 Mar 2009, at 18:38, Freddie Manners wrote:
I've been worrying about what happens when monads end up caught inside an
Event stream, as they inevitably do. Usually this is the IO monad, & usually it's not a problem because adaptE deals with Event (IO a) types eventually. But look at the following (contrived) example:
I read lots of people's mail. I have a load of buttons which add a person's mail to the set I receive, summarised by: addPerson :: Event Person I want an event of all the mail I get. Given: getMail :: Person -> Event Mail I can do: allMail :: Event Mail allMail = addPerson >>= getMail But realistically, I might have to create a new event for each person, or look the event up in a database or something. Then I have only: getMailM :: Person -> IO (Event Mail)
Why might that be the type? This sounds like the getMail function, only with a chunk of legacy adapter exposed in your pure code.
Also, these fixes will only stand a chance with IO (or ST, maybe); what if
getMailM :: Person -> State Foo (Event Mail) ?
The simple answer is – don't! IO and State are methods of describing time based computation, but we already have a lovely pure functional description of time based computation – Reactive. Your IO should end in the legacy adapter.
Bob_______________________________________________ Reactive mailing list Reactive@haskell.org http://www.haskell.org/mailman/listinfo/reactive