<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <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 class="moz-txt-link-freetext" href="https://github.com/ghc-proposals/ghc-proposals/pull/412">https://github.com/ghc-proposals/ghc-proposals/pull/412</a> /
      <a class="moz-txt-link-freetext" href="https://github.com/ghc-proposals/ghc-proposals/pull/243">https://github.com/ghc-proposals/ghc-proposals/pull/243</a></p>
    <p> - The parallelism work currently be planned in
<a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/ghc/ghc/-/wikis/Plan-for-increased-parallelism-and-more-detailed-intermediate-output">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 class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=nUvKoG_V_U0">https://www.youtube.com/watch?v=nUvKoG_V_U0</a> /
      <a class="moz-txt-link-freetext" href="https://github.com/gelisam/klister">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 class="moz-cite-prefix">On 3/30/21 10:14 AM, Richard Eisenberg
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:010f0178837c2155-3d83b309-0bf4-4321-90a1-694a1936f811-000000@us-east-2.amazonses.com">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br class="">
      <div><br class="">
        <blockquote type="cite" class="">
          <div class="">On Mar 30, 2021, at 4:57 AM, Alfredo Di Napoli
            <<a href="mailto:alfredo.dinapoli@gmail.com" class=""
              moz-do-not-send="true">alfredo.dinapoli@gmail.com</a>>
            wrote:</div>
          <br class="Apple-interchange-newline">
          <div class=""><span style="caret-color: rgb(0, 0, 0);
              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; -webkit-text-stroke-width: 0px;
              text-decoration: none; float: none; display: inline
              !important;" class="">I'll explore the idea of adding a
              second IORef.</span></div>
        </blockquote>
      </div>
      <br class="">
      <div class="">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 class=""><br class="">
      </div>
      <div class="">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 class=""><br class="">
      </div>
      <div class="">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 class=""><br class="">
      </div>
      <div class="">Richard</div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
ghc-devs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
    </blockquote>
  </body>
</html>