Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...
Simon Peyton Jones
simonpj at microsoft.com
Thu Sep 10 13:16:43 UTC 2020
And for sure the *parser* should not depend on the *desugarer* and *typechecker*. (Which it does, as described below.)
S
From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Sebastian Graf
Sent: 10 September 2020 14:12
To: Sylvain Henry <sylvain at haskus.fr>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...
Hey Sylvain,
In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753453548&sdata=fVpIzJgaqFfWaJ5ppCE5daHwdETTQF03o1h0uNtDxGA%3D&reserved=0> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=HZMaqK6t7PLifc26wf%2BqcUef4Ko%2BQcaPRx4o7XLcVq8%3D&reserved=0> 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=sn9zv1MO8p%2FSbwsm1NDaSiUaumE%2FvTo4NkGreYOjITA%3D&reserved=0> and https://gitlab.haskell.org/ghc/ghc/-/issues/11301<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=vFTEuEzIQLJTtpu7%2BuwFnOEWMPv8eY%2B%2FvgbrrV18uss%3D&reserved=0> 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/5d4862e8/attachment.html>
More information about the ghc-devs
mailing list