Thanks.  The (non-contrived) motivation was related to trying to link external databases into reactive code; my attempts to make legacy adapters for database calls seemed very unnatural, so Event (IO a) everywhere looked like an option.  I will give the pure approach another hack.

Freddie

2009/3/24 Conal Elliott <conal@conal.net>
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 <tom.davie@gmail.com> wrote:

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