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

[Sebastian Graf]

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