Proposal: Allow passing in linkable files from TH

[Moritz Angermann]

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:

- https://mail.haskell.org/pipermail/haskell-cafe/2017-September/127877.html
  in which aditya siram (deech) asks about linking non-c build objects.
- https://github.com/haskell/cabal/issues/4677
  in which Trevor McDonell describes his troubles linking non-c built object
  files.
- https://twitter.com/deech/status/910309231785660418
  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
comment[1].

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 irc.freenode.net/#ghc
or via email. I'm happy to help out.

-- 
[1]: https://ghc.haskell.org/trac/ghc/ticket/14298#comment:4
[2]: https://phabricator.haskell.org/D3608

> On Oct 3, 2017, at 11:58 AM, Alec Theriault <alec.theriault at gmail.com> 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]: https://ghc.haskell.org/trac/ghc/ticket/14298
>   [1]: https://hackage.haskell.org/package/inline-c
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs