<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 <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>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">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"><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">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>
        </blockquote>
      </div>
    </blockquote>
  </div>

</blockquote></div>