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 <sylv...@haskus.fr >: > 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
