[GHC] #11028: Refactor ConDecl
GHC
ghc-devs at haskell.org
Wed Nov 25 22:17:25 UTC 2015
#11028: Refactor ConDecl
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: alanz
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.2
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by alanz):
The key factor is the work currently done in `rnConResult`,
{{{#!hs
rnConResult doc _con details (ResTyGADT ls ty)
= do { (ty', fvs) <- rnLHsType doc ty
; let (arg_tys, res_ty) = splitHsFunType ty'
-- We can finally split it up,
-- now the renamer has dealt with fixities
-- See Note [Sorting out the result type] in RdrHsSyn
; case details of
InfixCon {} -> pprPanic "rnConResult" (ppr ty)
-- See Note [Sorting out the result type] in RdrHsSyn
RecCon {} -> do { unless (null arg_tys)
(addErr (badRecResTy doc))
; return (details, ResTyGADT ls res_ty, fvs)
}
PrefixCon {} -> return (PrefixCon arg_tys, ResTyGADT ls res_ty,
fvs)}
}}}
`splitHsFunTy` on `t -> MaybeO a b` will return `([t],MaybeO a b)`, and
the latter is then returned as the new `res_ty`
My understanding is that we are doing this so that the ParsedSource more
accurately reflects what was seen, which can simplify the API Annotations
work.
Perhaps we should add a `PostRn` field to the `ConDeclGADT` to capture the
new `details` and `res_ty`.
Alternatively, everything except the `rnLHsType` in `rnConResult` can move
to the type checking.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11028#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list