<div dir="ltr">From what you've said, it sounds like you can already write:<div><br></div><div> serverSide :: IO a -> Form a</div><div><br></div><div>This seems elegant enough to me for your needs. Just encourage it as an idiom specific to Forms.</div>
<div><br></div><div> myBlogForm = Blog <$> titleForm <*> serverSide getCurrentTime <*> contentsForm</div><div><br></div><div>Could you abstract `serverSide` out into a typeclass, such as ApplicativeIO? Sure. but why bother? The point is, you've got the specialization you need already.</div>
</div><div class="gmail_extra"><br clear="all"><div>-- Dan Burton</div>
<br><br><div class="gmail_quote">On Tue, Oct 1, 2013 at 1:20 AM, Tom Ellis <span dir="ltr"><<a href="mailto:tom-lists-haskell-cafe-2013@jaguarpaw.co.uk" target="_blank">tom-lists-haskell-cafe-2013@jaguarpaw.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Oct 01, 2013 at 09:29:00AM +0200, Niklas Haas wrote:<br>
</div><div class="im">> On Tue, 1 Oct 2013 02:21:13 -0500, John Lato <<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>> wrote:<br>
> > It's not a solution per se, but it seems to me that there's no need for the<br>
> > Monad superclass constraint on MonadIO. If that were removed, we could<br>
> > just have<br>
> ><br>
> > class LiftIO t where<br>
> > liftIO :: IO a -> t a<br>
> ><br>
> > and it would Just Work.<br>
><br>
> One concern with this is that it's not exactly clear what the semantics<br>
> are on LiftIO (is liftIO a >> liftIO b equal to liftIO (a >> b) or not?)<br>
> and the interaction between LiftIO and Applicative/Monad would have to<br>
> be some sort of ugly ad-hoc law like we have with Bounded/Enum etc.<br>
<br>
</div>Shouldn't it be an *Applicative* constraint?<br>
<br>
class Applicative t => ApplicativeIO t where<br>
<div class="im"> liftIO :: IO a -> t a<br>
<br>
</div>and require that<br>
<br>
liftIO (pure x) = pure x<br>
liftIO (f <*> x) = liftIO f <*> liftIO x<br>
<br>
Seems like ApplicativeIO makes more sense than MonadIO, which is<br>
unnecessarily restrictive. With planned Functor/Applicative/Monad shuffle,<br>
the former could completely replace the latter.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tom<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>