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

[Ben Gamari]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200914/0e7c2859/attachment.sig>