Hello folks, Richard: as I was in the middle of some other refactoring by the time Simon replied, you can see a potential refactoring that *doesn't* use the double IORef, but rather this idea of having a `DsMessage` embed `TcRnMessage`(s) via a new costructor:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4798/diffs#6eaba7424490cb26d74e0dab0f6fd7bc3537dca7 (Just grep for "DsMessage", "DsUnknownMessage", and `DsLiftedTcRnMessage` to see the call sites). The end result is not bad, I have to say. Or, at least, it doesn't strike me as totally horrid :) A. On Tue, 30 Mar 2021 at 16:14, Richard Eisenberg <r...@richarde.dev> wrote: > > > On Mar 30, 2021, at 4:57 AM, Alfredo Di Napoli <alfredo.dinap...@gmail.com> > wrote: > > I'll explore the idea of adding a second IORef. > > > Renaming/type-checking is already mutually recursive. (The renamer must > call the type-checker in order to rename -- that is, evaluate -- untyped > splices. I actually can't recall why the type-checker needs to call the > renamer.) So we will have a TcRnError. Now we see that the desugarer ends > up mixed in, too. We could proceed how Alfredo suggests, by adding a second > IORef. Or we could just make TcRnDsError (maybe renaming that). > > What's the disadvantage? Clients will have to potentially know about all > the different error forms with either approach (that is, using my combined > type or using multiple IORefs). The big advantage to separating is maybe > module dependencies? But my guess is that the dependencies won't be an > issue here, due to the fact that these components are already leaning on > each other. Maybe the advantage is just in having smaller types? Maybe. > > I don't have a great sense as to what to do here, but I would want a clear > reason that e.g. the TcRn monad would have two IORefs, while other monads > will work with GhcMessage (instead of a whole bunch of IORefs). > > Richard >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
