<div dir="ltr"><div><div>If I replace it with<br><br><br>mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext RdrName -> LHsType RdrName -> HsType RdrName<br>-- Smart constructor for HsForAllTy<br>-- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty<br>mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) (L noSrcSpan []) ty<br>mkHsForAllTy exp tvs ctxt     ty = HsForAllTy exp extra   (mkHsQTvs tvs) cleanCtxt        ty<br>  where -- Separate the extra-constraints wildcard when present<br>        (cleanCtxt, extra)<br>          | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init `fmap` ctxt, Just l)<br>          | otherwise = (ctxt, Nothing)<br>        ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the annotation here<br>        ignoreParens ty                 = ty<br><br></div><br>I get the following errors in the stage 2 compile (only first 3 shown here)<br><br><br>libraries/ghc-prim/GHC/Classes.hs:52:19:<br>    Malformed instance: (Eq a, Eq b) => Eq (a, b)<br><br>libraries/ghc-prim/GHC/Classes.hs:53:19:<br>    Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c)<br><br>libraries/ghc-prim/GHC/Classes.hs:54:19:<br>    Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d)<br><br><br><br></div>Alan<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div link="blue" vlink="purple" lang="EN-GB">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Hmm.  I’m not sure what the motivation is either.  Try dropping it out and see if anything goes wrong.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><br>
Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif" lang="EN-US">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif" lang="EN-US"> ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>]
<b>On Behalf Of </b>Alan & Kim Zimmerman<br>
<b>Sent:</b> 09 April 2015 22:15<br>
<b>To:</b> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<b>Subject:</b> Collapsing HsForAllTy, again<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">With the help of Jan Stolarek I tracked down the HsForAllTy flattening to<br>
 `HsTypes.mk_forall_ty`.</span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">This function takes any nested HsForAllTy's where the top one does not have a context defined, and collapses them into a single one.</span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">I do not know what the motivation for this is, and if it perhaps speeds up or simplifies further compilation.</span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">But now that API Annotations have arrived, making sure we do not lose the annotations for the sub-HsForAllTy  causes significant gymnastics in the parser [1].</span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">So my question is, is there a good reason to continue doing this, given the trade-off in parser complexity.</span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">Regards</span><u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">  Alan</span><u></u><u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Arial",sans-serif">[1]</span>  <a href="https://phabricator.haskell.org/D833" target="_blank">
https://phabricator.haskell.org/D833</a><u></u><u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
</div>

</blockquote></div><br></div>