<div dir="ltr"><div>Hi Sylvain,</div><div><br></div><div>Thanks, that answers all my questions! Keep up the great work.</div><div><br></div><div>Cheers<br></div><div>Sebastian<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Do., 10. Sept. 2020 um 17:24 Uhr schrieb Sylvain Henry <<a href="mailto:sylvain@haskus.fr">sylvain@haskus.fr</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>Hi Sebastian,</p>
    <p>Last month I tried to make a DynFlags-free parser. The branch is
      here:
      <a href="https://gitlab.haskell.org/hsyl20/ghc/-/commits/hsyl20/dynflags/parser" target="_blank">https://gitlab.haskell.org/hsyl20/ghc/-/commits/hsyl20/dynflags/parser</a>
      (doesn't build iirc)</p>
    <p>1) The input of the parser is almost DynFlags-free thanks to
      Alec's patch [1]. On that front, we just have to move
      `mkParserFlags` out of GHC.Parser. I would put it alongside other
      functions generating config datatypes from DynFlags in
      GHC.Driver.Config (added yesterday). It's done in my branch and it
      only required a bit of plumbing to fix `lexTokenStream` iirc.</p>
    <p>2) The output of the parser is the issue, as you point out. The
      main issue is that it uses SDoc/ErrMsg which are dependent on
      DynFlags.</p>
    <p>In the branch I've tried to avoid the use of SDoc by using ADTs
      to return errors and warnings so that the client of the parser
      would be responsible for converting them into SDoc if needed. This
      is the approach that we would like to generalize [2]. The ADT
      would look like [3] and the pretty-printing module like [4]. The
      idea was that ghc-lib-parser wouldn't integrate the
      pretty-printing module to avoid the dependencies.<br>
    </p>
    <p>I think it's the best interface (for IDEs and other tools) so we
      just have to complete the work :). The branch stalled because I've
      tried to avoid SDoc even in the pretty-printing module and used
      Doc instead of SDoc but it wasn't a good idea... I'll try to
      resume the work soon.<br>
    </p>
    <p>In the meantime I've been working on making Outputable/SDoc
      independent of DynFlags. If we merge [5] in some form then the
      last place where we use `sdocWithDynFlags` will be in CLabel's
      Outputable instance (to fix this I think we could just depend on
      the PprStyle (Asm or C) instead of querying the backend in the
      DynFlags). This could be another approach to make the parser
      almost as it is today independent of DynFlags. A side-effect of
      this work is that ghc-lib-parser could include the pretty-printing
      module too.<br>
    </p>
    <p>So to answer your question:<br>
    </p>
    <p>> Would you say it's reasonable to abstract the definition of
      `PState` over the `DynFlags` type?</p>
    <p>We're close to remove the dependence on DynFlags so I would
      prefer this instead of trying to abstract over it.</p>
    <p>The roadmap:</p>
    <p><tt>1. Make Outputable/SDoc independent of DynFlags</tt><tt><br>
      </tt><tt>1.1 Remove sdocWithDynFlags used to query the platform
        (!3972)<br>
        1.2 Remove sdocWithDynFlags used to query the backend in
        CLabel's Outputable instance<br>
        1.3 Remove sdocWithDynFlags<br>
        2. Move mkParserFlags from GHC.Parser to GHC.Driver.Config<br>
        3. (Make the parser use ADTs to return errors/warnings)</tt><br>
    </p>
    <p>Cheers,<br>
      Sylvain<br>
    </p>
    <p>[1]
<a href="https://gitlab.haskell.org/ghc/ghc/-/commit/469fe6133646df5568c9486de2202124cb734242" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/commit/469fe6133646df5568c9486de2202124cb734242</a><br>
      [2]
      <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values</a><br>
      [3]
<a href="https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors.hs" target="_blank">https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors.hs</a><br>
      [4]
<a href="https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors/Ppr.hs" target="_blank">https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors/Ppr.hs</a><br>
      [5] <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3972" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3972</a><br>
    </p>
    <p><br>
    </p>
    <div>On 10/09/2020 15:12, Sebastian Graf
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>Hey Sylvain,</div>
        <div><br>
        </div>
        <div>In <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971</a>
          I had to fight once more with the transitive dependency set of
          the parser, the minimality of which is crucial for <a href="https://hackage.haskell.org/package/ghc-lib-parser" target="_blank">ghc-lib-parser</a> and tested by the
          CountParserDeps test.</div>
        <div><br>
        </div>
        <div>I discovered that I need to make (parts of) `DsM` abstract,
          because it is transitively imported from the Parser for
          example through Parser.y -> Lexer.x -> DynFlags ->
          Hooks -> {DsM,TcM}.</div>
        <div>Since you are our mastermind behind the "Tame DynFlags"
          initiative, I'd like to hear your opinion on where progress
          can be/is made on that front.</div>
        <div><br>
        </div>
        <div>I see there is <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/10961" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/10961</a>
          and <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/11301" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/11301</a>
          which ask a related, but different question: They want a
          DynFlags-free interface, but I even want a DynFlags-free
          *module*.</div>
        <div><br>
        </div>
        <div>Would you say it's reasonable to abstract the definition of
          `PState` over the `DynFlags` type? I think it's only used for
          pretty-printing messages, which is one of your specialties
          (the treatment of DynFlags in there, at least).</div>
        <div>Anyway, can you think of or perhaps point me to an existing
          road map on that issue?</div>
        <div><br>
        </div>
        <div>Thank you!</div>
        <div>Sebastian<br>
        </div>
      </div>
    </blockquote>
  </div>

</blockquote></div>