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

[GHC]

#11425: The GHC API doesn't provide a good hscTarget option for tooling
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  high              |            Milestone:  8.2.1
       Component:  GHC API           |              Version:  7.10.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Other             |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by osa1:

@@ -16,1 +16,1 @@
-    * [https://github.com/DanielG/ghc-mod/pull/145|Fails} to issue pattern
+    * [https://github.com/DanielG/ghc-mod/pull/145 Fails] to issue pattern

New description:

 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#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler