Collapsing HsForAllTy, again

[Alan & Kim Zimmerman]

If I replace it with


mkHsForAllTy :: HsExplicitFlag -> [LHsTyVarBndr RdrName] -> LHsContext
RdrName -> LHsType RdrName -> HsType RdrName
-- Smart constructor for HsForAllTy
-- mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty
mkHsForAllTy exp tvs (L _ []) ty = HsForAllTy exp Nothing (mkHsQTvs tvs) (L
noSrcSpan []) ty
mkHsForAllTy exp tvs ctxt     ty = HsForAllTy exp extra   (mkHsQTvs tvs)
cleanCtxt        ty
  where -- Separate the extra-constraints wildcard when present
        (cleanCtxt, extra)
          | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init
`fmap` ctxt, Just l)
          | otherwise = (ctxt, Nothing)
        ignoreParens (L _ (HsParTy ty)) = ty -- TODO:AZ We lose the
annotation here
        ignoreParens ty                 = ty


I get the following errors in the stage 2 compile (only first 3 shown here)


libraries/ghc-prim/GHC/Classes.hs:52:19:
    Malformed instance: (Eq a, Eq b) => Eq (a, b)

libraries/ghc-prim/GHC/Classes.hs:53:19:
    Malformed instance: (Eq a, Eq b, Eq c) => Eq (a, b, c)

libraries/ghc-prim/GHC/Classes.hs:54:19:
    Malformed instance: (Eq a, Eq b, Eq c, Eq d) => Eq (a, b, c, d)



Alan

On Fri, Apr 10, 2015 at 12:14 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Hmm.  I’m not sure what the motivation is either.  Try dropping it out
> and see if anything goes wrong.
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Alan
> & Kim Zimmerman
> *Sent:* 09 April 2015 22:15
> *To:* ghc-devs at haskell.org
> *Subject:* Collapsing HsForAllTy, again
>
>
>
> With the help of Jan Stolarek I tracked down the HsForAllTy flattening to
>  `HsTypes.mk_forall_ty`.
>
> This function takes any nested HsForAllTy's where the top one does not
> have a context defined, and collapses them into a single one.
>
> I do not know what the motivation for this is, and if it perhaps speeds up
> or simplifies further compilation.
>
> 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].
>
> So my question is, is there a good reason to continue doing this, given
> the trade-off in parser complexity.
>
> Regards
>
>   Alan
>
> [1]  https://phabricator.haskell.org/D833
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150410/87387e56/attachment.html>