<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-12-16 8:53 GMT+01:00 Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de" target="_blank">lemming@henning-thielemann.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Storable is intended for data exchange with code written in other languages. Thus we must use the same alignment rules as the system ABI.</blockquote><div><br></div><div>As already mentioned above, Storable is meant as a *basic* building block for doing that, without a reference to any ABI whatsoever. Another use case for Storable is e.g. marshaling things into some form suitable for serialization, which might have nothing to do with any system ABI. So the conclusion that Storable must somehow obey some alignment rules is not correct: *You* as the author of a Storable instance for a give purpose have to care about alignment/packing/etc.</div><div><br></div><div>Taking a step back: An ABI like <a href="https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf">https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf</a> specifies a lot of things:</div><div><br></div><div>   * OS interface</div><div>   * File formats</div><div>   * Handling of exceptions</div><div>   * Linking</div><div>   * The calling convention for C (data types, data layout, registers, stack frames, ...)</div><div>   * ...</div><div><br></div><div>Even the calling convention for C++ is left out of most such ABI documents (perhaps available as a separate addendum), other languages are most of the time not even mentioned. *Some* calling convention has to be specified, otherwise you would have a hard time specifying the OS interface, and C is still the most natural choice for that. The FFI spec just gives you a small fraction of such an ABI:</div><div><br></div><div>   * A way to call C land, because you can't construct the right stack frame/register contents from Haskell land</div><div>   * A way to call back from C to Haskell</div><div>   * A very basic tooling to (un)marshal primitive data types and arrays of them (Storable)</div><div><br></div><div>Note that Storable itself is intentionally not tied to the ABI, it could as well be used to e.g. marshal packed graphics data to OpenGL etc. The right approach IMHO is to have separate classes for the various ABIs:</div><div><br></div><div>   * StorableAMD64</div><div>   * Storablex86</div><div>   * StorableARM32</div><div>   * StorableARM64</div><div>   * ...</div><div><br></div><div>Those classes would handle alignment/ordering issues for their respective platform, and we can have more instances for them, including sum types. Perhaps even a packed variant of these classes might be needed. In addition, perhaps an alias (subclass?) "StorableNative" of one of those classes represents the native ABI on the platform the program is running is needed, but then cross-compilation will be tricky.</div><div><br></div><div>I'm very open to extending the FFI toolset, but let's not retroactively interpret stuff into already existing things, at the danger of breaking an unknown amount of code.</div><div><br></div><div>Cheers,</div><div>    S.</div></div></div></div>