Changes between Version 2 and Version 3 of ExtendedPluginsProposal


Ignore:
Timestamp:
Jan 24, 2018 5:08:49 AM (20 months ago)
Author:
lazac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ExtendedPluginsProposal

    v2 v3  
    4040
    4141
    42 **Motivation**:
     42== Motivation
    4343
    44 Let's say we want to visualize the function dependency graph of bindings in a complex project, like GHC itself. [http://hackage.haskell.org/package/SourceGraph SourceGraph] can already do this kind of analysis, but it requires an input of a cabal file or a module name to do it. In case a cabal file is given, it parses it with the Cabal API to get the modules to run the analysis on. However to be able to use the tool conveniently on a large project such as GHC, one needs to take in consideration how Cabal or GHC is called during the build procedure. Additionally, although using the Cabal API to parse cabal files is convenient, but translating the data in the cabal file to instructions how GHC API should be used is not trivial.
     44Let's say we want to visualize the function dependency graph of bindings in a complex project, like GHC itself. [http://hackage.haskell.org/package/SourceGraph SourceGraph] can already do this kind of analysis, but it requires an input of a Cabal file or a module name to do it. In case a cabal file is given, it parses it with the Cabal API to get the modules to run the analysis on. However to be able to use the tool conveniently on a large project such as GHC, one needs to take in consideration how Cabal or GHC is called during the build procedure. Additionally, although using the Cabal API to parse cabal files is convenient, but translating the data in the cabal file to instructions how GHC API should be used is not trivial.
    4545
    46 What can enable development tools to work with complex projects in their own build environment is the inversion of control. Instead of the tool trying to figure out how to invoke the compiler to parse and typecheck the modules, it would be much better if it would be invoked by the compiler with the kind of program representation it needs. Plugin arguments will not alter the compiler mode or the compilation
     46The ideal solution would be to **extract the information about the source code** of a big Haskell project **during the normal build procedure**, since in this case we don't have to figure out how to compile its parts. What can enable development tools to work with complex projects in their own build environment is the inversion of control. Instead of the tool trying to figure out how to invoke the compiler to parse and typecheck the modules, it would be much better if it would be invoked by the compiler with the kind of program representation it needs. Plugin arguments will not alter the compiler mode or the compilation
    4747
    48 [https://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks Compiler hooks] could be used, but they cannot be controlled by simply configuring GHC at runtime. So a tool developer would have to create an alternative GHC that has some additional hooks and users would have to replace their GHC executable with the altered one. This means that it is unlikely that multiple tools could be used together.
     48== Existing methods
    4949
    50 [https://downloads.haskell.org/~ghc/master/users-guide/extending_ghc.html#frontend-plugins Frontend plugins] are not applicable, because their usage changes the major mode of the compiler. Some walkarounds can be used (like creating a wrapper for GHC), but they suffer from the same problems as using compiler hooks. Also check [https://ghc.haskell.org/trac/ghc/ticket/14018]
     50[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#compiler-plugins Compiler Plugins] would be the best to use, but currently they are only able to access the core reprsentation and install type checker plugins, which are not good for tools that want to analyze/manipulate the code at the source level.
     51
     52[https://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks Compiler hooks] could be used, but they cannot be controlled by simply configuring GHC at runtime. In order to install new hooks, the tool developer would have to create an alternative compiler executable and users would have to replace their GHC executable with the altered one. This means that it is unlikely that multiple tools could be used together.
     53
     54[https://downloads.haskell.org/~ghc/master/users-guide/extending_ghc.html#frontend-plugins 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. If the build environment already uses these flags, the frontend flag cannot be simply added. Some walkarounds can be used (like creating a wrapper for GHC), but they suffer from the same problems as using compiler hooks. Also check [https://ghc.haskell.org/trac/ghc/ticket/14018]