#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: | -------------------------------------+------------------------------------- Changes (by DanielG): * cc: DanielG (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11425#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Comment (by ezyang): Re pattern checker warnings see #10600. Re nothing versus interpreted, if Haskell separated the compile-time/run- time phases more closely, it would be easier to only interpret code that was going to be used for TH. http://blog.ezyang.com/2016/07/what-template- haskell-gets-wrong-and-racket-gets-right/ -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11425#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old 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).

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