[Haskell-cafe] How to write a pure String to String function in Haskell FFI to C++
carter.schonwald at gmail.com
Mon Jun 3 09:06:37 CEST 2013
as the others have said, if you want to have text data go between ghc and
c++, please use Text or Bytestring,
String... would get weird.
If you seriously want to experiment with writing low level code
manipulating the String type, it *MIGHT* be possible using the GHC C minus
minus (CMM). This would be very very very subtle to do correctly, and also
just be really really complicated and hard.
Likewise, for writing a "pure" looking ffi function, a good example is in
the lz4hs lib, where all the allocation occurs on the haskell side, and the
ffi is only mutating freshly allocated memory. Subject to this,
unsafePerformIO can be safely used to give a safe pure thread safe api.
On Sun, Jun 2, 2013 at 10:55 PM, Chris Wong <chrisyco+haskell-cafe at gmail.com
> > The C++/C function (e.g. toUppers) is computation-only and as pure as cos
> > and tan. The fact that marshaling string incurs an IO monad in current
> > examples is kind of unintuitive and like a bug in design. I don't mind
> > making redundant copies under the hood from one type to another..
> If you can guarantee that the call is pure, then you can execute it
> directly using `unsafePerformIO`. Simply call the external function as
> usual, then invoke `unsafePerformIO` on the result.
> See <
> On another note, if you really care about performance, you should use
> the `bytestring` and `text` packages instead of String. They are
> implemented in terms of byte arrays, instead of linked lists, hence
> are both faster and more FFI-friendly.
> > On Sun, Jun 2, 2013 at 8:08 PM, Brandon Allbery <allbery.b at gmail.com>
> >> On Sun, Jun 2, 2013 at 8:01 PM, Thomas Davie <tom.davie at gmail.com>
> >>> On 2 Jun 2013, at 16:48, Brandon Allbery <allbery.b at gmail.com> wrote:
> >>> (String is a linked list of Char, which is also not a C char; it is a
> >>> constructor and a machine word large enough to hold a Unicode
> codepoint. And
> >>> because Haskell is non-strict, any part of that linked list can be an
> >>> unevaluated thunk which requires forcing the evaluation of arbitrary
> >>> code elsewhere to "reify" the value; this obviously cannot be done in
> >>> middle of random C code, so it must be done during marshalling.)
> >>> I'm not convinced that that's "obvious" – though it certainly requires
> >>> functions (that go through the FFI) to grab each character at a time.
> >> I think you underestimate the complexity of the Haskell runtime and the
> >> interactions between it and the FFI. Admittedly it is probably not
> >> in the sense of "anyone can tell without knowing anything about it that
> >> can't possibly work", but it should be at least somewhat obvious to
> >> who sees why there needs to be an FFI in the first place that the
> >> is not trivial, and that they probably should not blindly assume that
> >> only reason one can't just pass Haskell values directly to C is that
> >> GHC developer was feeling lazy at the time.
> >> --
> >> brandon s allbery kf8nh sine nomine
> >> associates
> >> allbery.b at gmail.com
> >> ballbery at sinenomine.net
> >> unix, openafs, kerberos, infrastructure, xmonad
> >> http://sinenomine.net
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> Chris Wong, fixpoint conjurer
> e: lambda.fairy at gmail.com
> w: http://lfairy.github.io/
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe