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/469fe6133646df5568c9486de2202124cb734242
[2] https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values
[3]
https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors.hs
[4]
https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors/Ppr.hs
[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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
