<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-06-29 23:09 GMT+02:00 Brandon Allbery <span dir="ltr"><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Jun 29, 2015 at 5:05 PM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
On Mon, 29 Jun 2015, Evan Laforge wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think it's actually kind of overloaded, because it has haskell-only<br>
types like Char.<br>
</blockquote>
<br></span>
good point</blockquote><div><br></div></span><div>Hm. If it does so in any way other than specifying how they marshal to C types, that sounds like a problem with the definition of Storable. (Flip side, that marshaling is kinda the point of an FFI.)</div></div></div></div></blockquote><div><br></div><div>Actually there is nothing dangerous/overloaded/etc. at all: When we designed the FFI, we had 2 use cases in mind:</div><div><br></div><div>   * Bind some existing C stuff to Haskell. This is what CInt, CFloat, etc. are for.</div><div><br></div><div>   * Extend existing Haskell code with C: This is what HsInt, HsFloat etc. are for.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I'm against tuples in Storable because tuples don't exist in C, so<br>
you should really be using a record with a corresponding struct.<br>
</blockquote>
<br></span>
I have used them to call functions compiled by LLVM-JIT. LLVM supports tuple types. I guess that LLVM tuples are just structs without field names.</blockquote><div><br></div></span><div>LLVM does target more than just C (and therefore more than just C types). I think my question here is "is there an agreed-on ABI for these types, beyond LLVM's own?"</div></div></div></div></blockquote><div><br></div><div>We intentionally left out marshaling of compound structures out of the spec, because this would open (as we just see :-) a can of worms, even if we would restrict ourselves to just C. The FFI and the Storable instances in the report are just the necessary building blocks (which can't be expressed otherwise) for higher-level stuff and the intention was to use tools like c2hs etc. for more complicated things.</div><div><br></div><div>One more argument why Storable instances for tuples are a bad idea: To make this consistent, one would have to align 1-tuples (i.e. normal values like CFloat etc.), too, because most ABIs require this. But this is intentionally not what their instances do.</div></div></div></div>