<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hello folks,<div><br></div><div>as some of you might know me and Richard are reworking how GHC constructs, emits and deals with errors and warnings (See <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values">https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values</a> and #18516).</div><div><br></div><div>To summarise very briefly the spirit, we will have (eventually) proper domain-specific types instead of SDocs. The idea is to have very precise and "focused" types for the different phases of the compilation pipeline, and a "catch-all" monomorphic `GhcMessage` type used for the final pretty-printing and exception-throwing:</div><div><br></div><div><div>data GhcMessage where</div><div>  GhcPsMessage      :: PsMessage -> GhcMessage</div><div>  GhcTcRnMessage    :: TcRnMessage -> GhcMessage</div><div>  GhcDsMessage      :: DsMessage -> GhcMessage</div><div>  GhcDriverMessage  :: DriverMessage -> GhcMessage</div><div>  GhcUnknownMessage :: forall a. (Diagnostic a, Typeable a) => a -> GhcMessage</div></div><div><br></div><div>While starting to refactor GHC to use these types, I have stepped into something bizarre: the `DsGblEnv` and `TcLclEnv` envs both share the same `IORef` to store the diagnostics (i.e. warnings and errors) accumulated during compilation. More specifically, a function like `GHC.HsToCore.Monad.mkDsEnvsFromTcGbl` simply receives as input the `IORef` coming straight from the `TcLclEnv`, and stores it into the `DsGblEnv`.</div><div><br></div><div>This is unfortunate, because it would force me to change the type of this `IORef` to be</div><div>`IORef (Messages GhcMessage)` to accommodate both diagnostic types, but this would bubble up into top-level functions like `initTc`, which would now return a `Messages GhcMessage`. This is once again unfortunate, because is "premature": ideally it might still be nice to return `Messages TcRnMessage`, so that GHC API users could get a very precise diagnostic type rather than the bag `GhcMessage` is. It also violates an implicit contract: we are saying that `initTc` might return (potentially) *any* GHC diagnostic message (including, for example, driver errors/warnings), which I think is misleading.</div><div><br></div><div>Having said all of that, it's also possible that returning `Messages GhcMessage` is totally fine here and we don't need to be able to do this fine-grained distinction for the GHC API functions. Regardless, I would like to ask the audience:</div><div><br></div><div>* Why `TcLclEnv` and `DsGblEnv` need to share the same IORef?</div><div>* Is this for efficiency reasons?</div><div>* Is this because we need the two monads to independently accumulate errors into the</div><div>  same IORef?</div><div><br></div><div>Thanks!</div><div><br></div><div>Alfredo</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div>