Storable laws

Sven Panne svenpanne at gmail.com
Sun Dec 17 19:02:09 UTC 2017


2017-12-17 13:41 GMT+01:00 Henning Thielemann <lemming at henning-thielemann.de
>:

>
> On Sun, 17 Dec 2017, Merijn Verstraaten wrote:
>
> Tools like hsc2hs already pad the result of sizeOf to the appropriately
>> aligned size (at least the ones I've used), so this is a non-issue for that
>> scenario.
>>
>
> But that's tailored to C. If I understand Sven correctly, then this is not
> valid for Storable.


I'm not sure if I understand the concerns about hsc2hs here correctly, but
anyway: There are intentionally no Storable instances for struct-like
things in the FFI spec, but that doesn't rule out that one can define
instances for a special purpose (e.g. native ABI compliant ones) on your
own. hsc2hs, c2hs, GreenCard etc. are tools to help you with that (and much
more). This doesn't contradict anything in the FFI spec, you just choose
one of several possible semantics in your program for types which are not
even mentioned in the spec. OTOH, as an author of a general library I would
be very hesitant to define such instances, they might not be what the
library user expects.

Perhaps we really want to extend the FFI spec in such a way that only one
kind of instance makes sense for a given type (including complex ones),
e.g. by defining separate classes for the different purposes mentioned in
this thread. But this would need some serious design thoughts to get this
right and flexible enough while avoiding to break tons of FFI code already
out there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20171217/fead7540/attachment.html>


More information about the Libraries mailing list