Proposal: Allow passing in linkable files from TH

Moritz Angermann moritz at
Tue Oct 3 04:22:47 UTC 2017

Hi Alec,

I think this would be great to have.  Here are few other discussions that have
similar needs but do not necessarily have TH as a direct dependency:

  in which aditya siram (deech) asks about linking non-c build objects.
  in which Trevor McDonell describes his troubles linking non-c built object
  a follow up by deech again, on how to hack this with a custom Setup.hs

Now this is mostly cabal related. But the point I'd like to make is that a
complete solution that includes generating and linking object files from TH
should see if there is a way that this would play nice with cabal as well
(by possibly extending cabal a bit here). This might also tie in with bens

If you could upload your diff to Phabricator, I'd be happy to take a look and
give feedback wrt. to potential cross compilation implications (See also: D3608[2])

If you have trouble with phabricator, feel free to ask on
or via email. I'm happy to help out.


> On Oct 3, 2017, at 11:58 AM, Alec Theriault <alec.theriault at> wrote:
> Hello,
> I have a TH feature request and I'd like to hear what people have to say about it. Here is the [Trac ticket][0].
> I'm new to this, so if anything here sounds completely wrong, it probably is.
> TH currently lets you add in arbitrary C (and other languages usually supported by C compilers).
> That code is compiled for you and then linked in automatically. This is what makes the
> [`inline-c`][1] package possible.
> I'm proposing to extend this so that TH lets you pass in something that is already compiled and
> ready to be linked. The idea is that this would allow TH-level FFI to any language that can
> produce object files or libraries that have the C ABI. My immediate use-case is to make an
> `inline-rust` package where one can write Rust code straight into a Haskell quasiquote.
> In terms of a concrete API change, it would suffice to
>   1. add a `LangLinkable` constructor to the `ForeignSrcLang` data type
>   2. add a `qAddForeignFilePath :: ForeignSrcLang -> FilePath -> m ()` method to `Quasi`
> The code change is pretty small too (60 additions, 30 deletions) since the `addForeignFile`
> machinery is fully reusable (we just have to skip past the phase of calling the C compiler).
> # Pros:
>   * Better TH FFI support
>   * Simple to implement
> # Cons:
>   * The proposed API is suboptimal: it allows for `qAddForeignFile LangLinkable "..."` although that 
>  that pretty much never makes sense since the thing being linked is not subject to `String`  encoding
> Any thoughts?
> Alec
>   [0]:
>   [1]:
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

More information about the ghc-devs mailing list