<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Sebastian,</p>
<p>Last month I tried to make a DynFlags-free parser. The branch is
here:
<a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/hsyl20/ghc/-/commits/hsyl20/dynflags/parser">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 class="moz-txt-link-freetext" href="https://gitlab.haskell.org/ghc/ghc/-/commit/469fe6133646df5568c9486de2202124cb734242">https://gitlab.haskell.org/ghc/ghc/-/commit/469fe6133646df5568c9486de2202124cb734242</a><br>
[2]
<a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values">https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values</a><br>
[3]
<a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors.hs">https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors.hs</a><br>
[4]
<a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors/Ppr.hs">https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors/Ppr.hs</a><br>
[5] <a class="moz-txt-link-freetext" href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3972">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3972</a><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 10/09/2020 15:12, Sebastian Graf
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hey Sylvain,</div>
<div><br>
</div>
<div>In <a
href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">https://gitlab.haskell.org/ghc/ghc/-/issues/10961</a>
and <a
href="https://gitlab.haskell.org/ghc/ghc/-/issues/11301"
moz-do-not-send="true">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>
</body>
</html>