<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">But NB: The wart would be much less warty if it was only an abstract syntax tree. Then it would have practically NO dependencies! The only wartiness is that if f :: DynFlags -> bha, it’s hard
to tell how much of DynFlags f reads. That’s a software engineering issue, but a much less painful one than having giant module dependency loops.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-devs <ghc-devs-bounces@haskell.org>
<b>On Behalf Of </b>Moritz Angermann<br>
<b>Sent:</b> 18 September 2020 14:56<br>
<b>To:</b> Adam Gundry <adam@well-typed.com>; Sylvain Henry <sylvain@haskus.fr><br>
<b>Cc:</b> ghc-devs <ghc-devs@haskell.org><br>
<b>Subject:</b> Re: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
I'm not certain anything in HEAD actually breaks any plugin today. But the whole idea of plugins having full access to what currently is "DynFlags" is not something I believe we can sustain. <a href="mailto:sylvain@haskus.fr">@Sylvain Henry</a> is currently
cleaning up a lot of unnecessary DynFlags usage. I'm not against keeping the necessary infrastructure for hooks and other interfaces with plugins, but I'd like to advocate towards not expecting DynFlags to keep existing in eternity. If we assume a subset of
what used to be in DynFlags to be relevant to Plugins, let's collect that in say PluginHooks, but let's keep that interface minimal. And maybe that can be specified to stay stable.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
DynFlags is our state kitchensink in GHC, and it is everywhere. The state is threaded through everything and the module is gargantuous. So far there seemed to be broad support in removing this wart.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Cheers, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Moritz<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Fri, Sep 18, 2020 at 5:52 PM Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On 14/09/2020 13:02, Moritz Angermann wrote:<br>
> I believe this to already be broken in HEAD. DynFlags already got quite<br>
> an overhaul/break. I'd rather we drop supporting DynFlagPlugins. And<br>
> offer alternative stable interfaces. Though to be honest, I believe our<br>
> Plugin story is rather poor so far.<br>
> <br>
> Do you happen to know of DynFlagPlugins, Adam?<br>
<br>
A few have been mentioned in the thread now. What specifically do you<br>
believe is broken in HEAD regarding DynFlags plugins, and is there an<br>
issue for it? AFAICS the hooks-plugin test which corresponds to the<br>
user's guide text is still there.<br>
<br>
I think it is important to retain the ability for plugins to manipulate<br>
both DynFlags and Hooks, whether the latter are separated out of the<br>
former or not. Both have legitimate use cases, and plugins necessarily<br>
involve using unstable interfaces (at least until someone designs a<br>
stable interface). I agree that the current state of plugins/hooks is<br>
somewhat ad-hoc and could do with more effort put into the design (like<br>
much else in the GHC API!) but that doesn't mean we should remove things<br>
that work already.<br>
<br>
Slightly tangential note: discussing this with Alp I learned about the<br>
log_action/dump_action/trace_action fields of DynFlags, which also seem<br>
to violate Simon's "We should think of DynFlags as an abstract syntax<br>
tree." And indeed it would be useful for plugins to be able to override<br>
log_action, especially combined with #18516, as then we would have a<br>
nice story for plugins overriding error message generation to allow for<br>
domain-specific error messages.<br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
> On Mon, Sep 14, 2020 at 7:09 PM Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a><br>
> <mailto:<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>>> wrote:<br>
> <br>
> 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://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending_ghc.html%23dynflags-plugins&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258108460&sdata=h6bor7jYE96tW%2BkICk%2BodTG9tbKkS4taiLyFLWmrRJE%3D&reserved=0" 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<br>
> 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><br>
> <mailto:<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> <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:* RE: Parser depends on DynFlags, depends on Hooks,<br>
> 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>
> ><br>
> <a href="https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending_ghc.html%23dynflags-plugins&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258118424&sdata=umpDUPC3uoHUnPtjah4L8iGnEOacnsFRGr4fT760CGQ%3D&reserved=0" 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>><br>
> > <mailto:<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>
> <mailto:<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>
> <mailto:<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<br>
> on TcM,<br>
> > DsM, ...<br>
> ><br>
> > <br>
> ><br>
> > Hey Sylvain,<br>
> ><br>
> > <br>
> ><br>
> > In <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%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258118424&sdata=2H%2FvZzMZOaoAyFEnvO2LSGpr4gIO4PYHPE6ynWr9eCo%3D&reserved=0" target="_blank">
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971</a><br>
> ><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%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258128372&sdata=dACDLVEDLpvpb8WUYmC2DHi%2FJ97d2AKeXRY6eNUMzgY%3D&reserved=0" 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>
> ><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%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258128372&sdata=c%2F68cNhMxm3HmewVAdc5iFaxkUJ4Dds2oCS2S62y2qw%3D&reserved=0" 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<br>
> Parser.y -><br>
> > Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.<br>
> ><br>
> > Since you are our mastermind behind the "Tame DynFlags"<br>
> initiative, I'd<br>
> > like to hear your opinion on where progress can be/is made on that<br>
> front.<br>
> ><br>
> > <br>
> ><br>
> > I see there is <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%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258138335&sdata=Qd0gnkQvpAFhjrkHmbU%2FJfhu39IfmRUgfXJbcNGr4UE%3D&reserved=0" target="_blank">
https://gitlab.haskell.org/ghc/ghc/-/issues/10961</a><br>
> ><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%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258138335&sdata=Qd0gnkQvpAFhjrkHmbU%2FJfhu39IfmRUgfXJbcNGr4UE%3D&reserved=0" 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258148291&sdata=L1ZzCHw4xZF2ZXxvBq8Ucb3cNPwjwGrrbRMXAd4NWKE%3D&reserved=0" target="_blank">
https://gitlab.haskell.org/ghc/ghc/-/issues/11301</a><br>
> ><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%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258148291&sdata=L1ZzCHw4xZF2ZXxvBq8Ucb3cNPwjwGrrbRMXAd4NWKE%3D&reserved=0" 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<br>
> DynFlags in<br>
> > there, at least).<br>
> ><br>
> > Anyway, can you think of or perhaps point me to an existing road<br>
> map on<br>
> > that issue?<br>
> ><br>
> > <br>
> ><br>
> > Thank you!<br>
> ><br>
> > Sebastian<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.well-typed.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258158247&sdata=jcKsOscvZDaemr6roAP%2BOVow5DrvPD4AYYsPsb%2BD0k8%3D&reserved=0" 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<o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>