Storable laws

[Sven Panne]

2017-12-16 8:53 GMT+01:00 Henning Thielemann <lemming at henning-thielemann.de>
:

> Storable is intended for data exchange with code written in other
> languages. Thus we must use the same alignment rules as the system ABI.


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.

Taking a step back: An ABI like
https://software.intel.com/sites/default/files/article/402129/mpx-linux64-abi.pdf
specifies a lot of things:

   * OS interface
   * File formats
   * Handling of exceptions
   * Linking
   * The calling convention for C (data types, data layout, registers,
stack frames, ...)
   * ...

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:

   * A way to call C land, because you can't construct the right stack
frame/register contents from Haskell land
   * A way to call back from C to Haskell
   * A very basic tooling to (un)marshal primitive data types and arrays of
them (Storable)

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:

   * StorableAMD64
   * Storablex86
   * StorableARM32
   * StorableARM64
   * ...

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.

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.

Cheers,
    S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20171216/98dee7e1/attachment.html>