Proposal: Allow passing in linkable files from TH

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

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
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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (2)
-
Alec Theriault
-
Moritz Angermann