[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:  (none)
            Type:  feature request   |               Status:  new
        Priority:  high              |            Milestone:
       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:                    |
-------------------------------------+-------------------------------------

Old description:

> Tools like [[https://github.com/DanielG/ghc-mod/|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).

New description:

 Tools like [[https://github.com/DanielG/ghc-mod/|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 (#10600)

 == 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).

--

Comment (by bgamari):

 Duog has provided an interesting approach to making `-fno-code` usable in
 the presence of Template Haskell. See ticket:8025#comment:7.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11425#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler