> 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 <http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html/System-IO-Unsafe.html>. 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 <allber...@gmail.com> wrote: >> >> On Sun, Jun 2, 2013 at 8:01 PM, Thomas Davie <tom.da...@gmail.com> wrote: >>> >>> On 2 Jun 2013, at 16:48, Brandon Allbery <allber...@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 Haskell >>> code elsewhere to "reify" the value; this obviously cannot be done in the >>> 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 "obvious" >> in the sense of "anyone can tell without knowing anything about it that it >> can't possibly work", but it should be at least somewhat obvious to someone >> who sees why there needs to be an FFI in the first place that the situation >> is not trivial, and that they probably should not blindly assume that the >> only reason one can't just pass Haskell values directly to C is that some >> GHC developer was feeling lazy at the time. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allber...@gmail.com >> ballb...@sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Chris Wong, fixpoint conjurer e: lambda.fa...@gmail.com w: http://lfairy.github.io/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
