<div dir="ltr">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.<div><br></div><div>Do you happen to know of DynFlagPlugins, Adam?</div><div><br></div><div>Cheers,</div><div> Moritz</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 14, 2020 at 7:09 PM Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm supportive of the goal, but a complication with removing hooks from<br>
DynFlags is that GHC currently supports "DynFlags plugins" that allow<br>
plugins to install custom hooks<br>
(<a href="https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins" rel="noreferrer" target="_blank">https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins</a>).<br>
I guess this can be worked around, perhaps by passing hooks separately<br>
to DynFlags and providing a separate plugin interface to modify hooks.<br>
But doing so will necessarily break existing plugins.<br>
<br>
Adam<br>
<br>
<br>
On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:<br>
> I thought I’d sent a message about this DynFlags thing, but I can’t<br>
> trace it now. So here’s a resend.<br>
> <br>
> <br>
> <br>
> Currently<br>
> <br>
> * The DynFlags record includes Hooks<br>
> * Hooks in contains functions, that mention TcM, DsM etc<br>
> <br>
> <br>
> <br>
> This is bad. We should think of DynFlags as an *abstract syntax tree*. <br>
> That is, the result of parsing the flag strings, yes, but not much<br>
> more. So for hooks we should have an algebraic data type representing<br>
> the hook /specification/, but it should not be the hook functions<br>
> themselves. HsSyn, for example, after parsing, is just a tree with<br>
> strings in it. No TyCons, Ids, etc. That comes much later.<br>
> <br>
> <br>
> <br>
> So DynFlags should be a collection of algebraic data types, but should<br>
> not depend on anything else.<br>
> <br>
> <br>
> <br>
> I think that may cut a bunch of awkward loops.<br>
> <br>
> <br>
> <br>
> Simon<br>
> <br>
> <br>
> <br>
> *From:*Simon Peyton Jones<br>
> *Sent:* 10 September 2020 14:17<br>
> *To:* Sebastian Graf <<a href="mailto:sgraf1337@gmail.com" target="_blank">sgraf1337@gmail.com</a>>; Sylvain Henry<br>
> <<a href="mailto:sylvain@haskus.fr" target="_blank">sylvain@haskus.fr</a>><br>
> *Cc:* ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>><br>
> *Subject:* RE: Parser depends on DynFlags, depends on Hooks, depends on<br>
> TcM, DsM, ...<br>
> <br>
> <br>
> <br>
> And for sure the **parser** should not depend on the **desugarer** and<br>
> **typechecker**. (Which it does, as described below.)<br>
> <br>
> <br>
> <a href="https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins" rel="noreferrer" target="_blank">https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins</a><br>
> S<br>
> <br>
> <br>
> <br>
> *From:*ghc-devs <<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a><br>
> <mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>>> *On Behalf Of *Sebastian Graf<br>
> *Sent:* 10 September 2020 14:12<br>
> *To:* Sylvain Henry <<a href="mailto:sylvain@haskus.fr" target="_blank">sylvain@haskus.fr</a> <mailto:<a href="mailto:sylvain@haskus.fr" target="_blank">sylvain@haskus.fr</a>>><br>
> *Cc:* ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a> <mailto:<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>>><br>
> *Subject:* Parser depends on DynFlags, depends on Hooks, depends on TcM,<br>
> DsM, ...<br>
> <br>
> <br>
> <br>
> Hey Sylvain,<br>
> <br>
> <br>
> <br>
> In <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971</a><br>
> <<a href="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" rel="noreferrer" target="_blank">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</a>><br>
> I had to fight once more with the transitive dependency set of the<br>
> parser, the minimality of which is crucial for ghc-lib-parser<br>
> <<a href="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" rel="noreferrer" target="_blank">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</a>><br>
> and tested by the CountParserDeps test.<br>
> <br>
> <br>
> <br>
> I discovered that I need to make (parts of) `DsM` abstract, because it<br>
> is transitively imported from the Parser for example through Parser.y -><br>
> Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.<br>
> <br>
> Since you are our mastermind behind the "Tame DynFlags" initiative, I'd<br>
> like to hear your opinion on where progress can be/is made on that front.<br>
> <br>
> <br>
> <br>
> I see there is <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/10961" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/10961</a><br>
> <<a href="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" rel="noreferrer" target="_blank">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</a>><br>
> and <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/11301" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/11301</a><br>
> <<a href="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" rel="noreferrer" target="_blank">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</a>><br>
> which ask a related, but different question: They want a DynFlags-free<br>
> interface, but I even want a DynFlags-free *module*.<br>
> <br>
> <br>
> <br>
> Would you say it's reasonable to abstract the definition of `PState`<br>
> over the `DynFlags` type? I think it's only used for pretty-printing<br>
> messages, which is one of your specialties (the treatment of DynFlags in<br>
> there, at least).<br>
> <br>
> Anyway, can you think of or perhaps point me to an existing road map on<br>
> that issue?<br>
> <br>
> <br>
> <br>
> Thank you!<br>
> <br>
> Sebastian<br>
<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
118 Wymering Mansions, Wymering Road, London W9 2NF, England<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>