> 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 <allbery.b@gmail.com> wrote:
>>
>> On Sun, Jun 2, 2013 at 8:01 PM, Thomas Davie <tom.davie@gmail.com> wrote:
>>>
>>> On 2 Jun 2013, at 16:48, Brandon Allbery <allbery.b@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
>> allbery.b@gmail.com
>> ballbery@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.fairy@gmail.com
  w: http://lfairy.github.io/

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe