<br><br><div class="gmail_quote">On Thu, Jul 3, 2008 at 7:31 PM, Claus Reinke &lt;<a href="mailto:claus.reinke@talk21.com">claus.reinke@talk21.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
GHC gives the error:<br>
<br>
 &nbsp; Couldn&#39;t match expected type `T f1 f1 a&#39;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;against inferred type `T f f a&#39;<br>
 &nbsp; In the expression: blah x<br>
 &nbsp; In the definition of `wrapper&#39;: wrapper x = blah x<br>
</blockquote>
<br></div>
actually, GHC gives me &quot;could not deduce Blah f a from Blah f1 a&quot;<br>
first. It seems that desugaring type function notation into an additional<br>
constraint helps, so there&#39;s something odd going on:</blockquote><div><br>Silly me, I didn&#39;t paste the whole type error. Yes, GHC gives both. I should add that I tested this under GHC <a href="http://6.8.2.">6.8.2.</a> But this is known not to work with a (one/two months old) GHC head.<br>
<br>Cheers,<br><br>Alexey<br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
 &nbsp; class Blah f a where blah :: a -&gt; T f f a<br>
 &nbsp; class A f where type T f :: (* -&gt; *) -&gt; * -&gt; *<br>
<br></div>
 &nbsp; wrapper :: forall a f tf . (Blah f a,T f~tf) =&gt; a -&gt; tf f a<br>
 &nbsp; wrapper x = blah x<br>
<br>
You&#39;re relying on that second f to determine the first, which<br>
then allows T f to determine tf f a. Looks a bit like cyclic<br>
programming at the type level?-) Whereas the desugared<br>
view is that we may not know the type constructor tf yet,<br>
but whatever it is, its first parameter fixes f.<br>
<br>
Yet another take on it: tf, the result of T f f a, needs to be<br>
determined by the context, rather than the type function,<br>
and type functions are traditionally bad at reasoning backwards. The extra indirection separates determining<br>
f from applying T f.<br>
<br>
I think I&#39;d prefer if that naive desugaring of type function<br>
always worked, without such differences.<br>
<br>
Worth a ticket?<br><font color="#888888">
Claus<br>
<br>
<br>
</font></blockquote></div><br>