Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

[Alp Mestanogullari]

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.

On 14/09/2020 21:20, Ben Gamari wrote:
> Moritz Angermann <moritz.angermann at gmail.com> writes:
>
>> 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.
>>
> 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:
>
>> 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.
> 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
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200914/1a3b379c/attachment.html>