The main problem with adding those in general is that then we have to get deeper into the business of packing and alignment. You need to add the spacers for when the second structure isn't aligned with the first, and the logic for that isn't cross-platform friendly. -Edward On Mon, Jun 29, 2015 at 11:04 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:

On Mon, 29 Jun 2015, Edward Kmett wrote:

Also, I wonder if () could be Storable:

...

instance Storable () where sizeOf _ = 0 alignment _ = 1 peek _ = return () poke _ _ = return ()

No objection from me to any of them; a very strong +1.

Btw. what about Storable (a,b) and Storable (a,b,c)?

It depends. The problem is ultimately that folks use Storable for many things. Sometimes it is native interop, but sometimes it is for serializing out to a known binary file format, etc. In the absence of these extra instances we do not have to choose its "real" role. If we added them then we'd start committing to one of those scenarios. -Edward On Mon, Jun 29, 2015 at 12:46 PM, Mike Izbicki wrote:

Are the alignment issues for tuples not something that CPP could fix?

...

The main problem with adding those in general is that then we have to get deeper into the business of packing and alignment. You need to add the spacers for when the second structure isn't aligned with the first, and

On Mon, Jun 29, 2015 at 8:18 AM, Edward Kmett wrote: the

...

logic for that isn't cross-platform friendly.

-Edward

On Mon, Jun 29, 2015 at 11:04 AM, Henning Thielemann wrote:

...

On Mon, 29 Jun 2015, Edward Kmett wrote:

...

Also, I wonder if () could be Storable:

instance Storable () where sizeOf _ = 0 alignment _ = 1 peek _ = return () poke _ _ = return ()

No objection from me to any of them; a very strong +1.

Btw. what about Storable (a,b) and Storable (a,b,c)?

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

2015-06-29 22:40 GMT+02:00 Henning Thielemann

:

On Mon, 29 Jun 2015, Edward Kmett wrote:

It depends. The problem is ultimately that folks use Storable for many

...

things. Sometimes it is native interop, but sometimes it is for serializing out to a known binary file format, etc. In the absence of these extra instances we do not have to choose its "real" role. If we added them then we'd start committing to one of those scenarios.

The Storable class is part of the FFI and thus I think we must comply to the system ABI.

-1 to obeying the system ABI blindly for tuples: There is the notion of packed structures, not everything using the FFI uses the system ABI (e.g. various OpenGL data structures), etc. Having some kind of support for the system ABI would be nice, but this should not be mixed with the Storable class IMHO.

On Mon, 29 Jun 2015, Brandon Allbery wrote:

On Mon, Jun 29, 2015 at 4:46 PM, Sven Panne wrote: -1 to obeying the system ABI blindly for tuples: There is the notion of packed structures, not everything using the FFI uses the system ABI (e.g. various OpenGL data structures), etc. Having some kind of support for the system ABI would be nice, but this should not be mixed with the Storable class IMHO.

The FFI being part of the Haskell Report, and Storable being necessary for implementation, I think it's on you to produce a new suitable class instead.

I think the same. For packed structures you would need a new PackedStorable class.

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

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.

2015-06-29 23:09 GMT+02:00 Brandon Allbery :

On Mon, Jun 29, 2015 at 5:05 PM, Henning Thielemann < lemming@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.