<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Yeah good point. Ultimately, I hope we can abstract over things
like the IORef itself so that while TcM can kick off DsM and
vice-versa, each monad can only log messages of the right type,
but that can come later.</p>
<p>Good luck, very excited to see this work happen!</p>
<p>John<br>
</p>
<div class="moz-cite-prefix">On 4/1/21 2:00 AM, Alfredo Di Napoli
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFqA6+WhjzQFQMhkcA4dKScxafKa7vfoJm8jabWNcKvP1LMhCg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hello all,
<div><br>
</div>
<div>John: right, I am not opposed to what you describe, but at
the end of the day we need to add all these messages to a
single IORef (unless we go with the two IORef idea that
Richard is not fond of), and for that we need a single
monomorphic type, which could be, initially, even something
like:</div>
<div><br>
</div>
<div>type TcRnDsMessage = Either DsMessage TcRnMessage</div>
<div><br>
</div>
<div>I guess I'll have to iterate on this until we get something
meaningful and that passes the full testsuite :)</div>
<div><br>
</div>
<div>A.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 31 Mar 2021 at 16:36,
John Ericson <a class="moz-txt-link-rfc2396E" href="mailto:john.ericson@obsidian.systems"><john.ericson@obsidian.systems></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>
<p>I might still be tempted to do:</p>
<div>
<div>data DsMessage =</div>
<div> ...</div>
<div> | DsLiftedTcRnMessage !TcRnMessage</div>
<div> -- ^ A diagnostic coming straight from the
Typecheck-renamer.</div>
<div><br>
</div>
<div>
<div>
<div>data TcRnMessage =</div>
<div> ...</div>
<div> | TcRnLiftedDsMessage !DsMessage</div>
<div> -- ^ A diagnostic coming straight from the
Desugarer.</div>
<div><br>
</div>
tying them together with hs-boot. Yes, that means one
can do some silly `TcRnLiftedDsMessage .
DsLiftedTcRnMessage . TcRnLiftedDsMessage ...`, but
that could even show up in a render as "while
desugaring a splice during type checking, while
typechecking during desguaring, ..." so arguably the
information the wrapping isn't purely superfluous.</div>
<div><br>
</div>
<div>I think this would pose no practical problem today,
while still "soft enforcing" the abstraction
boundaries we want.</div>
<div><br>
</div>
</div>
</div>
<div>On 3/31/21 3:45 AM, Alfredo Di Napoli wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Follow up:
<div><br>
</div>
<div>Argh! I have just seen that I have a bunch of
test failures related to my MR (which, needless to
say, it's still WIP).</div>
<div><br>
</div>
<div>For example:</div>
<div><br>
</div>
<div>
<div>run/T9140.run.stdout.normalised 2021-03-31
09:35:48.000000000 +0200</div>
<div>@@ -1,12 +1,4 @@</div>
<div> </div>
<div>-<interactive>:2:5:</div>
<div>- You can't mix polymorphic and unlifted
bindings: a = (# 1 #)</div>
<div>- Probable fix: add a type signature</div>
<div>-</div>
<div>-<interactive>:3:5:</div>
<div>- You can't mix polymorphic and unlifted
bindings: a = (# 1, 3 #)</div>
<div>- Probable fix: add a type signature</div>
<div>-</div>
</div>
<div><br>
</div>
<div>So it looks like some diagnostic is now not being
reported and, surprise surprise, this was emitted
from the DsM monad.</div>
<div><br>
</div>
<div>I have the suspect that indeed Richard was right
(like he always is :) ) -- when we go from a DsM to
a TcM monad (See `initDsTc`) for example, I think we
also need to carry into the new monad all the
diagnostics we collected so far.</div>
<div><br>
</div>
<div>This implies indeed a mutual dependency (as Simon
pointed out, heh).</div>
<div><br>
</div>
<div><br>
</div>
<div>So I think my cunning plan of embedding is
crumbling -- I suspect we would end up with a type
`TcRnDsMessage` which captures the dependency. </div>
<div><br>
</div>
<div>Sorry for not seeing it sooner!</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, 31 Mar 2021 at
08:05, Alfredo Di Napoli <<a
href="mailto:alfredo.dinapoli@gmail.com"
target="_blank" moz-do-not-send="true">alfredo.dinapoli@gmail.com</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 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>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>
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>
-- ^ 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>
| 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>
-- ^ 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>
-- 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><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>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><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></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 <a
href="mailto:john.ericson@obsidian.systems"
target="_blank" moz-do-not-send="true"><john.ericson@obsidian.systems></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>
<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" moz-do-not-send="true">https://github.com/ghc-proposals/ghc-proposals/pull/412</a>
/ <a
href="https://github.com/ghc-proposals/ghc-proposals/pull/243"
target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">https://www.youtube.com/watch?v=nUvKoG_V_U0</a>
/ <a
href="https://github.com/gelisam/klister"
target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">ghc-devs@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>