#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:
​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 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