[GHC] #11425: The GHC API doesn't provide a good hscTarget option for tooling

14 Jan 2016

      #11425: The GHC API doesn't provide a good hscTarget option for tooling
-------------------------------------+-------------------------------------
           Reporter:  bgamari        |             Owner:
               Type:  feature        |            Status:  new
  request                            |
           Priority:  high           |         Milestone:  8.2.1
          Component:  GHC API        |           Version:  7.10.3
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  Other
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Tools like ghc-mod typically just want `TypecheckedModule`s. Sadly, the
 GHC API currently doesn't provide a good way to get at these in all cases
 (see this [https://github.com/DanielG/ghc-mod/issues/205|ghc-mod ticket]).
 Each of the options we offer are cursed with their own limitations
 (largely quoting from the ghc-mod ticket),

 == HscNothing ==

 At first glance this looks like what you would want. But...

  * Pros
    * Doesn't generate code of any sort and is therefore rather lightweight
  * Cons
    * It lacks support for Template Haskell
    * Has trouble with `foreign export`s
    * [https://github.com/DanielG/ghc-mod/pull/145|Fails} to issue pattern
 match checker warnings

 == HscInterpreted ==

 Okay, so `HscNothing` doesn't work. Maybe `HscInterpreted` is better?

  * Pros
    * Supports Template Haskell
  * Cons
    * Can't deal with unboxed tuples (#1257)
    * Slower as we need to produce unnecessary bytecode
    * Large memory footprint
    * Also can't deal with `foreign export`s

 == HscAsm ==

  * Pros
    * Supports all compilable code
  * Cons
    * Slow
    * Produces `.o` files

 This is quite unfortunate. It seems like we need something in between
 `HscNothing` and `HscInterpreted` which is willing to use the interpreter
 to evaluate Template Haskell splices when necessary, but doesn't produce
 bytecode. Unfortunately it's unclear what to do about `foreign export`
 (but arguably most tools would be fine with some approximate
 representation).

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11425
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler