Proposal: Allow passing in linkable files from TH

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Allow passing in linkable files from TH

Alec Theriault
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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs