​Frontend plugins are not applicable, because their usage changes the major mode of the compiler. So if the tool developer wants to go on with
#14709: Extend the plugin mechanism to access program representation -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D4342 https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal| -------------------------------------+------------------------------------- Comment (by ezyang): This doesn't really have anything to do with the relative merits/demerits of the proposal, but I just wanted to point out: the compilation procedure, he must replicate what GHC would do if the frontend plugin was not used. Furthermore, it can't be inserted into a normal build environment, since using the --frontend flag clashes with other mode flags like --make or --interactive. Out of the box these statements are true, but as I mention in http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api-programs-with- cabal/ there are some relatively simple tricks you can play to solve this problem. As another example, https://github.com/ezyang/ghc-shake comes with a wrapper program which overrides the meaning of `--make` but otherwise keeps all other major modes the same. Of course, if the frontend plugin is replacing a mode like `--make`, it needs to understand all of the same arguments that `--make` would have understood, but that is what you would expect, no? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14709#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler