Moritz Angermann <moritz.angerm...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
