Hi Sylvain,
Thanks, that answers all my questions! Keep up the great work.
Cheers
Sebastian
Am Do., 10. Sept. 2020 um 17:24 Uhr schrieb Sylvain Henry : Hi Sebastian, Last month I tried to make a DynFlags-free parser. The branch is here:
https://gitlab.haskell.org/hsyl20/ghc/-/commits/hsyl20/dynflags/parser
(doesn't build iirc) 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. 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. 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. 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. 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. So to answer your question: Would you say it's reasonable to abstract the definition of `PState`
over the `DynFlags` type? We're close to remove the dependence on DynFlags so I would prefer this
instead of trying to abstract over it. The roadmap: 1. Make Outputable/SDoc independent of DynFlags
1.1 Remove sdocWithDynFlags used to query the platform (!3972)
1.2 Remove sdocWithDynFlags used to query the backend in CLabel's
Outputable instance
1.3 Remove sdocWithDynFlags
2. Move mkParserFlags from GHC.Parser to GHC.Driver.Config
3. (Make the parser use ADTs to return errors/warnings) Cheers,
Sylvain [1]
https://gitlab.haskell.org/ghc/ghc/-/commit/469fe6133646df5568c9486de2202124...
[2]
https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values
[3]
https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler...
[4]
https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler...
[5] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3972 On 10/09/2020 15:12, Sebastian Graf wrote: Hey Sylvain, In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971 I had to
fight once more with the transitive dependency set of the parser, the
minimality of which is crucial for ghc-lib-parser
https://hackage.haskell.org/package/ghc-lib-parser and tested by the
CountParserDeps test. 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}.
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. I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961 and
https://gitlab.haskell.org/ghc/ghc/-/issues/11301 which ask a related,
but different question: They want a DynFlags-free interface, but I even
want a DynFlags-free *module*. 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).
Anyway, can you think of or perhaps point me to an existing road map on
that issue? Thank you!
Sebastian