<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Morning all,<div><br></div><div><b>Richard</b>: sorry! Unfortunately MR !4798 is the cornerstone of this refactoring work but it's also gargantuan. Let's discuss a plan to attack it, but fundamentally there is a critical mass of changes that needs to happen atomically or it wouldn't make much sense, and alas this doesn't play in our favour when it comes to MR size and ease of review. However, to quickly reply to your remak: currently (for the sake of the "minimum-viable-product") I am trying to stabilise the external interfaces, by which I mean giving functions their final type signature while I do what's easiest to make things typecheck. In this phase what I think is the easiest is to wrap the majority of diagnostics into the `xxUnknownxx` constructor, and change them gradually later. A fair warning, though: you say "<span style="color:rgb(26,26,26);font-family:Arial;font-size:13px">I would think that a DsMessage would later be wrapped in an envelope." This might be true for Ds messages (didn't actually invest any brain cycles to check that) but in general we have to turn a message into an envelope as soon as we have a chance to do so, because we need to grab the `SrcSpan` and the `DynFlags` *at the point of creation* of the diagnostics. Carrying around a message and make it bubble up at some random point won't be a good plan (even for Ds messages). Having said that, I clearly have very little knowledge about this area of GHC, so feel free to disagree :)</span></div><div><span style="color:rgb(26,26,26);font-family:Arial;font-size:13px"><br></span></div><div><span style="color:rgb(26,26,26);font-family:Arial;font-size:13px"><b>John</b>: Although it's a bit hard to predict how well this is going to evolve, my current embedding, to refresh everyone's memory, is the following:</span></div><div><span style="color:rgb(26,26,26);font-family:Arial;font-size:13px"><br></span></div><div><p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span style="-webkit-font-kerning: none;">data DsMessage =</span></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span style="-webkit-font-kerning: none;"> DsUnknownMessage !DiagnosticMessage</span></p><p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span style="-webkit-font-kerning: none;"> -- ^ Stop-gap constructor to ease the migration.</span></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span style="-webkit-font-kerning: none;"> | DsLiftedTcRnMessage !TcRnMessage</span></p>
<p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span style="-webkit-font-kerning: none;"> -- ^ A diagnostic coming straight from the Typecheck-renamer.</span></p><p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span style="-webkit-font-kerning: none;"> -- More messages added in the future, of course</span></p><p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span style="-webkit-font-kerning: none;"><br></span></p><p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span style="-webkit-font-kerning: none;">At first I thought this was the wrong way around, due to Simon's comment, but this actually creates pleasant external interfaces. To give you a bunch of examples from MR !4798:</span></p><p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span style="-webkit-font-kerning: none;"><br></span></p><p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)"><span style="-webkit-font-kerning: none;"></span></p><p style="margin:0px;font-stretch:normal;font-size:13px;line-height:normal;font-family:Arial;color:rgb(26,26,26)">deSugar :: HscEnv -> ModLocation -> TcGblEnv -> IO (Messages DsMessage, Maybe ModGuts)</p></div><div><div>deSugarExpr :: HscEnv -> LHsExpr GhcTc -> IO (Messages DsMessage, Maybe CoreExpr)</div></div><div><br></div><div>Note something interesting: the second function actually calls `runTcInteractive` inside the body, but thanks to the `DsLiftedTcRnMessage` we can still expose to the consumer an opaque `DsMessage` , which is what I would expect to see from a function called "deSugarExpr". Conversely, I would be puzzled to find those functions returning a `TcRnDsMessage`.</div><div><br></div><div><br></div><div>Having said all of that, I am not advocating this design is "the best". I am sure we will iterate on it. I am just reporting that even this baseline seems to be decent from an API perspective :)</div><div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 31 Mar 2021 at 05:45, John Ericson <john.ericson@obsidian.systems> 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>
<p>Alfredo also replied to this pointing his embedding plan. I also
prefer that, because I really wish TH didn't smear together the
phases so much. Moreover, I hope with</p>
<p> - GHC proposals
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/412" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/412</a> /
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/243" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/243</a></p>
<p> - The parallelism work currently be planned in
<a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/Plan-for-increased-parallelism-and-more-detailed-intermediate-output" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/wikis/Plan-for-increased-parallelism-and-more-detailed-intermediate-output</a>
<br>
</p>
<p>we might actually have an opportunity/extra motivation to do
that. Splices and quotes will still induce intricate inter-phase
dependencies, but I hope that could be mediated by the driver
rather than just baked into each phase.</p>
<p>(One final step would be the "stuck macros" technique of
<a href="https://www.youtube.com/watch?v=nUvKoG_V_U0" target="_blank">https://www.youtube.com/watch?v=nUvKoG_V_U0</a> /
<a href="https://github.com/gelisam/klister" target="_blank">https://github.com/gelisam/klister</a>, where TH splices would be able
to making "blocking queries" of the the compiler in ways that
induce more of these fine-grained dependencies.)</p>
<p>Anyways, while we could also do a "RnTsDsError" and split later,
I hope Alfredo's alternative of embedding won't be too much harder
and prepare us for these exciting areas of exploration.<br>
</p>
<p>John</p>
<div>On 3/30/21 10:14 AM, Richard Eisenberg
wrote:<br>
</div>
<blockquote type="cite">
<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>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
ghc-devs mailing list
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>