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.<br>
<br>Freddie<br><br><div class="gmail_quote">2009/3/24 Conal Elliott <span dir="ltr"><<a href="mailto:conal@conal.net">conal@conal.net</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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<br>
<br><div class="gmail_quote"><div><div></div><div class="h5">On Mon, Mar 23, 2009 at 3:48 PM, Thomas Davie <span dir="ltr"><<a href="mailto:tom.davie@gmail.com" target="_blank">tom.davie@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">
<div><br>
On 23 Mar 2009, at 18:38, Freddie Manners wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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:<br>
<br>
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:<br>
addPerson :: Event Person<br>
I want an event of all the mail I get. Given:<br>
getMail :: Person -> Event Mail<br>
I can do:<br>
allMail :: Event Mail<br>
allMail = addPerson >>= getMail<br>
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:<br>
getMailM :: Person -> IO (Event Mail)<br>
</blockquote>
<br></div>
Why might that be the type? This sounds like the getMail function, only with a chunk of legacy adapter exposed in your pure code.<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, these fixes will only stand a chance with IO (or ST, maybe); what if getMailM :: Person -> State Foo (Event Mail) ?<br>
</blockquote>
<br>
<br></div>
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.<br>
<br></div></div>
Bob_______________________________________________<br>
Reactive mailing list<br>
<a href="mailto:Reactive@haskell.org" target="_blank">Reactive@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/reactive" target="_blank">http://www.haskell.org/mailman/listinfo/reactive</a><br>
</blockquote></div><br>
</blockquote></div><br>