[reactive] Monads in Event streams

[Freddie Manners]

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)
So,
fmap getMailM addPerson :: Event (IO (Event Mail))
and there is no longer a function (like "join" above) for getting an Event
Mail, an Event (IO Mail), an IO (Event Mail) or even an IO (Event (IO Mail))
out of that as things stand.

Given a clock, I could do something like:--
undoIO :: Clock t -> Event (IO a) -> IO (Event a)
undoIO c e = do
    (sink, e') <- makeEvent c
    forkIO $ adaptE (>>= sink) e
    return e'
But having a clock lying around seems wrong; and I'd ideally like the new
Event to be simultaneous with the old one (provided getMailM finishes
quickly).  I could also do this an old-fashioned way by passing around event
sinks; but again that's not really in the spirit.

Also, these fixes will only stand a chance with IO (or ST, maybe); what if
getMailM :: Person -> State Foo (Event Mail) ?

So, can a function be constructed with the desired type (say Event (m (Event
a)) -> m (Event a)), or is that unreasonable to expect?  Is there a
(generalizable) alternative way of doing this example which doesn't require
one?  This seems a natural thing to want to do.

Freddie Manners
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/reactive/attachments/20090323/2995c2e8/attachment.htm