<div dir="ltr"><div dir="ltr"><div dir="ltr">Hello folks,<div><br></div><div>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:</div><div><br></div><div><a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4798/diffs#6eaba7424490cb26d74e0dab0f6fd7bc3537dca7">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4798/diffs#6eaba7424490cb26d74e0dab0f6fd7bc3537dca7</a><br></div><div><br></div><div>(Just grep for "DsMessage", "DsUnknownMessage", and `DsLiftedTcRnMessage` to see the call sites).</div><div><br></div><div>The end result is not bad, I have to say. Or, at least, it doesn't strike me as totally horrid :)</div><div><br></div><div>A.</div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 30 Mar 2021 at 16:14, Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Mar 30, 2021, at 4:57 AM, Alfredo Di Napoli <<a href="mailto:alfredo.dinapoli@gmail.com" target="_blank">alfredo.dinapoli@gmail.com</a>> wrote:</div><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">I'll explore the idea of adding a second IORef.</span></div></blockquote></div><br><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>Richard</div></div></blockquote></div>