Thanks for your answers so far.<br><br>It seems that the laziness of String or [char] is the problem.<br><br>My question boils then down to this. There are plenty of Haskell FFI examples where simple things like sin/cos in <math.h> can be imported into Haskell as pure functions. Is there a way to extend that to String without introducing an IO (), but maybe sacrificing laziness?<br>
If String has to be lazy, is there another Haskell data type convertible to String that can do the job?<br><br>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..<br>
<br><br><br><br><div class="gmail_quote">On Sun, Jun 2, 2013 at 8:08 PM, Brandon Allbery <span dir="ltr"><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="im">On Sun, Jun 2, 2013 at 8:01 PM, Thomas Davie <span dir="ltr"><<a href="mailto:tom.davie@gmail.com" target="_blank">tom.davie@gmail.com</a>></span> wrote:</div><div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im"><div><div>On 2 Jun 2013, at 16:48, Brandon Allbery <<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>> wrote:</div>
</div></div><div class="im"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>(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.)</div>
</div></div></div></blockquote><br></div></div><div class="im"><div>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.</div>
</div></div></blockquote>
<div><br></div><div>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.</div>
</div><div class="im"><div><br></div>-- <br><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div>
<div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div>
</div></div></div>
</blockquote></div><br>