+1 to adding the Applicative and the constraint on Quasi.<br><br><div class="gmail_quote">On Fri, Jul 8, 2011 at 6:33 AM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On Fri, Jul 8, 2011 at 12:56 PM, Bas van Dijk <<a href="mailto:v.dijk.bas@gmail.com">v.dijk.bas@gmail.com</a>> wrote:<br>
> Hello,<br>
><br>
> The Q type:<br>
><br>
> newtype Q a = Q { unQ :: forall m. Quasi m => m a }<br>
><br>
> currently has an instance for Monad and Functor. I would like to<br>
> propose adding an instance for Applicative as well. Note that this<br>
> also means that the Quasi class needs to get an Applicative<br>
> superclass:<br>
><br>
> class (Monad m, Applicative m, Functor m) => Quasi m where ...<br>
><br>
> Discussion period: 2 weeks.<br>
><br>
> Regards,<br>
><br>
> Bas<br>
><br>
</div></div>> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
><br>
><br>
<br>
+1. But wouldn't it be possible to do this without the Applicative<br>
superclass, using the Monad instance? Not saying we *should* do that,<br>
I'm in favor of your proposal exactly as-is.<br></blockquote><div><br></div><div>Using the Monad constraint only, prevents you from working polymorphically in the Quasi instance while using Applicative combinators. You wind up having to carry around both instances. A burden would be borne by everyone who uses TH, rather than the 2-3 people who write Quasi instances. ;)</div>
<div><br></div><div>-Edward</div></div>