I believe this to already be broken in HEAD. DynFlags already got quite an overhaul/break. I'd rather we drop supporting DynFlagPlugins. And offer alternative stable interfaces. Though to be honest, I believe our Plugin story is rather poor so far.
Do you happen to know of DynFlagPlugins, Adam? Cheers, Moritz On Mon, Sep 14, 2020 at 7:09 PM Adam Gundry <a...@well-typed.com> wrote: > I'm supportive of the goal, but a complication with removing hooks from > DynFlags is that GHC currently supports "DynFlags plugins" that allow > plugins to install custom hooks > ( > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins > ). > I guess this can be worked around, perhaps by passing hooks separately > to DynFlags and providing a separate plugin interface to modify hooks. > But doing so will necessarily break existing plugins. > > Adam > > > On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote: > > I thought I’d sent a message about this DynFlags thing, but I can’t > > trace it now. So here’s a resend. > > > > > > > > Currently > > > > * The DynFlags record includes Hooks > > * Hooks in contains functions, that mention TcM, DsM etc > > > > > > > > This is bad. We should think of DynFlags as an *abstract syntax tree*. > > That is, the result of parsing the flag strings, yes, but not much > > more. So for hooks we should have an algebraic data type representing > > the hook /specification/, but it should not be the hook functions > > themselves. HsSyn, for example, after parsing, is just a tree with > > strings in it. No TyCons, Ids, etc. That comes much later. > > > > > > > > So DynFlags should be a collection of algebraic data types, but should > > not depend on anything else. > > > > > > > > I think that may cut a bunch of awkward loops. > > > > > > > > Simon > > > > > > > > *From:*Simon Peyton Jones > > *Sent:* 10 September 2020 14:17 > > *To:* Sebastian Graf <sgraf1...@gmail.com>; Sylvain Henry > > <sylv...@haskus.fr> > > *Cc:* ghc-devs <ghc-devs@haskell.org> > > *Subject:* RE: Parser depends on DynFlags, depends on Hooks, depends on > > TcM, DsM, ... > > > > > > > > And for sure the **parser** should not depend on the **desugarer** and > > **typechecker**. (Which it does, as described below.) > > > > > > > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins > > S > > > > > > > > *From:*ghc-devs <ghc-devs-boun...@haskell.org > > <mailto:ghc-devs-boun...@haskell.org>> *On Behalf Of *Sebastian Graf > > *Sent:* 10 September 2020 14:12 > > *To:* Sylvain Henry <sylv...@haskus.fr <mailto:sylv...@haskus.fr>> > > *Cc:* ghc-devs <ghc-devs@haskell.org <mailto:ghc-devs@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 > > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 118 Wymering Mansions, Wymering Road, London W9 2NF, England > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
