<div dir="ltr"><div dir="ltr"><div dir="ltr"><br><div>> <span style="color:rgb(26,26,26);font-family:Arial;font-size:13px">Do you happen to know of DynFlagPlugins, Adam?</span></div><div><span style="color:rgb(26,26,26);font-family:Arial;font-size:13px"><br></span></div><div><span style="color:rgb(26,26,26);font-family:Arial;font-size:13px">Alas the newly release LiquidHaskell plugin relies on the `dynflagsPlugin` action, so it would be nice if this was not removed:</span></div><div><span style="color:rgb(26,26,26);font-family:Arial;font-size:13px"><br></span></div><div><a href="https://github.com/ucsd-progsys/liquidhaskell/blob/develop/src/Language/Haskell/Liquid/GHC/Plugin.hs#L146">https://github.com/ucsd-progsys/liquidhaskell/blob/develop/src/Language/Haskell/Liquid/GHC/Plugin.hs#L146</a><span style="color:rgb(26,26,26);font-family:Arial;font-size:13px"><br></span></div><div><br></div><div>Ignoring the other options, we rely on `Opt_KeepRawTokenStreams` which is *key* for the correct behaviour of the plugin. If we were not intercepting the `DynFlags` at this stage, the lexer would drop any block comments from the parsed sources and we wouldn't have the chance of parsing the LH annotations contained within.</div><div><br></div><div>Now, truth to be told, due to the fact we ended up re-parsing each module anyway (for unfortunate reasons) we *could* survive without it by tweaking the `DynFlags` inside the `ModSummary` before we call `parseModule`, but in an ideal world we wouldn't need this, and we would be using directly the parsed source that the `parsedResultAction` would give us. Without the `dynflagsPlugin` I don't think we would be able to do that anymore.</div><div><br></div><div><br></div><div><span style="color:rgb(26,26,26);font-family:Arial;font-size:13px"><br></span></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 14 Sep 2020 at 23:20, Alp Mestanogullari <<a href="mailto:alp@well-typed.com">alp@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<p>My original motivation for !1580 and !1827 (the latter of which
ended up getting merged) would be equally well supported by an
interface with more limited scope. My only requirement there was
to be able to override the meta hook. I therefore would not mind
going back to the approach I initially took, in !1580, which I
preferred back then already. As long as we leave a way for plugins
to override hooks, my use case will not suffer.<br>
</p>
<div>On 14/09/2020 21:20, Ben Gamari wrote:<br>
</div>
<blockquote type="cite">
<pre>Moritz Angermann <a href="mailto:moritz.angermann@gmail.com" target="_blank"><moritz.angermann@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre>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.
</pre>
</blockquote>
<pre>To fill in a bit of history here, DynFlags plugins were introduced in
!1827, which arose as an alternative to !1580. The latter proposed a
much more specialised interface specifically allowing plugins to
introduce Hooks. Personally, I far prefer the approach taken in !1580. To
quote my comment on !1580:
</pre>
<blockquote type="cite">
<pre>I agree that overriding DynFlags is excessive and, moreover, it
entrenches the structure of DynFlags as a semi-stable interface. In my
opinion the current state of DynFlags is a very uneasy compromise and
really should be refactored (at very least split up into smaller
records). While it's true that the Hsc capability given to parser
plugins allows DynFlags to be modified, I would consider this to be
very much a backdoor and not a supported use.
Hooks, on the other hand, are intended to be extension points for the
compiler. Consequently it is quite natural for them to be set by
plugins.
</pre>
</blockquote>
<pre>In light of how quickly DynFlags is now changing, I somewhat regret not
pushing back more vigorously against the DynFlags-centric approach. I
tend to agree that we should remove the interface and revert to a more
limited interface that simply deals in Hooks.
Cheers,
- Ben
</pre>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
ghc-devs mailing list
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
</div>
_______________________________________________<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>