Missing instance declarations in base

[Sven Panne]

2015-06-29 23:09 GMT+02:00 Brandon Allbery <allbery.b at gmail.com>:

> On Mon, Jun 29, 2015 at 5:05 PM, Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>>
>> On Mon, 29 Jun 2015, Evan Laforge wrote:
>>
>>  I think it's actually kind of overloaded, because it has haskell-only
>>> types like Char.
>>>
>>
>> good point
>
>
> 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.)
>

Actually there is nothing dangerous/overloaded/etc. at all: When we
designed the FFI, we had 2 use cases in mind:

   * Bind some existing C stuff to Haskell. This is what CInt, CFloat, etc.
are for.

   * Extend existing Haskell code with C: This is what HsInt, HsFloat etc.
are for.


>  So I'm against tuples in Storable because tuples don't exist in C, so
>>> you should really be using a record with a corresponding struct.
>>>
>>
>> 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.
>
>
> 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?"
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150630/83619f82/attachment-0001.html>