Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

[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/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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200910/ff707722/attachment.html>