Separate Module AST from GhcPass
#18936 (closed) was closed out, but there was one glaring omission: HsModule
.
In #17642 (closed) / !2423 (closed), HsModule
was made momomorphic in GhcPs
. But per the principle that the unextended AST should be "complete", I think that should be reverted, and a new Language.Haskell.Syntax.Module
made.
What @int-index wrote in #17642 (closed) is also interesting (to me at least) and relevant here:
Actually, I would rather see the opposite happen. The renamer could take
HsModule GhcPs
as input and produceHsModule GhcRn
as output.It is fairly strange that we have
type ParsedSource = Located (HsModule GhcPs) type RenamedSource = (HsGroup GhcRn, [LImportDecl GhcRn], Maybe [(LIE GhcRn, Avails)], Maybe LHsDocString) type TypecheckedSource = LHsBinds GhcTc
instead of
type ParsedSource = Located (HsModule GhcPs) type RenamedSource = Located (HsModule GhcRn) type TypecheckedSource = Located (HsModule GhcTc)
@RyanGlScott scott pointed out issues like [HsDecl p]
vs HsGroup p
would need to be resolved, but this doesn't daunt me. We are dealing with somewhat similar issues in !4782 (closed) right now (though I think !4782 (closed) is harder!), and so I don't doubt we could fix things here to.
(Probably the answer is the HsGroup
should just be included in HsModule
. HsGroup
is currently not included in any other GHC-agnostic AST node.)
Finally, note per !4778 (comment 324914) this will necessitate splitting GHC.Hs.Doc
and GHC.Hs.ImpExp
too.